Growing Object-Oriented Software Google Group

Re: [GOOS] Presenter-first design

josuesan...@gmail.com (Josue Barbosa dos Santos) — Tue, 21 May 2013 17:08:42 UT

Yes.

one AT. and this one AT imply in one or more unit tests. The ATs always
guide what has to be done.

--
Abraços,
Josué
[link]

Re: [GOOS] Presenter-first design

rpin...@gmail.com (Rick Pingry) — Tue, 21 May 2013 16:33:42 UT

That is way cool, Josué. So you keep the one set of AT's running fast for
the developers to run often, and allow the slow ones that actually hit the
web boundary to run on your build server. But I guess the key thing there
is to avoid duplication across those 2 environments so that really both are

Re: [GOOS] Presenter-first design

josuesan...@gmail.com (Josue Barbosa dos Santos) — Mon, 20 May 2013 19:36:04 UT

Hello Rick,

Sorry for the delay (weekend and a bit busy here). The projects are
organized more or less like this (Pseudo Java):

As I said we have two types of Acceptance Tests (direct calls and the web).
So we have one class to each type:

@RunWith(Suite.class)
@Suite.SuiteClasses((
UseCaseTests.class

Re: Slow acceptance tests

anthony.charles.gr...@gmail.com (Anthony Green) — Mon, 20 May 2013 16:34:55 UT

Like most things, it depends.
On your current understanding of their individual purpose and value.
On how that understanding is different today to what it was yesterday.
As your heuristical sense of design and test smells matures (a process that
never ends BTW) you'd get better at picking the best choice for that moment.

Re: [GOOS] Slow acceptance tests

ke...@rutherford-software.com (Kevin Rutherford) — Mon, 20 May 2013 11:24:37 UT

Hi,

I would definitely NOT do this.

If the tests are painfuly slow, that pain is telling you a lot about
your design. Keep the tests slow until the design is fixed. And if you
absolutely must have some very slow full-stack tests, push them into a
batch job that runs asynchronously to your TDD cycle; if any of these

Re: [GOOS] Slow acceptance tests

m...@mattwynne.net (Matt Wynne) — Mon, 20 May 2013 09:46:48 UT

Hi James,

For me, a top-heavy testing pyramid (or testing ice-cream cone as some people call it) is a sign of problems. Here are some of my thoughts on the subject:

[link]

Also some more buried in here:

Re: [GOOS] Slow acceptance tests

zodiac...@gmail.com (Colin Vipurs) — Mon, 20 May 2013 08:37:49 UT

In addition - parallelise your tests and get them running concurrently,
spreading across multiple hardware if you need to on the CI server.

--
Maybe she awoke to see the roommate's boyfriend swinging from the
chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.

Re: [GOOS] Slow acceptance tests

s...@claysnow.co.uk (Seb Rose) — Mon, 20 May 2013 08:34:13 UT

It's also worth remembering that when you are /specifically/ testing the UI
you may be able to do this without testing the rest of the system.

Put another way: you can *unit* test your UI

--
ACCU - Professionalism in Programming - [link]

[link]
[link]

Re: [GOOS] Slow acceptance tests

d...@dhemery.com (Dale Emery) — Sun, 19 May 2013 19:56:52 UT

Hi James,

My first preference is to avoid the UI altogether /except/ for the (relatively) few cases where the UI is part of what I'm testing.

For most acceptance tests, I want to bypass the UI. For this to be a reasonable test of the (nearly) whole system, I have to make sure the UI that I'm bypassing does very, very little work. If possible, I want the UI to do two things: 1. Translate user gestures into a single method call on a controller. 2. Draw stuff on the screen when notified that some relevant information has changed.

Slow acceptance tests

floehop...@gmail.com (James Mead) — Sun, 19 May 2013 17:00:39 UT

Developing an application outside-in tends to lead to the growth of an
extensive acceptance test suite. These tests are often slow to run. A slow
build means delayed feedback and makes development painful. How do people
tackle this? Which of the following tactics would you recommend using and
which would you caution against? Are there any other useful tactics worth

Re: [GOOS] Presenter-first design

torbj...@kalin-urena.com (Torbjörn Kalin) — Sun, 19 May 2013 11:23:47 UT

Good questions :)

The first days or even weeks on a greenfield project I probably spend as
much time refactoring the code as I do implementing new behavior. And I
probably spend as much time refactoring the tests as I do refactoring the
production code. The test code is no second class citizen but requires as

Re: [GOOS] Presenter-first design

rpin...@gmail.com (Rick Pingry) — Sat, 18 May 2013 06:12:31 UT

So, Josué,

How do you like to organize your AT's so that they serve the best as
documentation? It seems that they aren't really organized by classes.
Perhaps they are organized by user stories or by interface screens or
features or something like that?

-- Rick

Re: [GOOS] Presenter-first design

johnny.smith2...@gmail.com (Johnny Smith) — Sat, 18 May 2013 06:09:16 UT

Thank you for your replies Steve and Josué.

Looks like it's a matter of skill and experience to decide which acceptance
test to write. If that's so, then I have to practice much more to decide
when is the right time to write acceptance tests when it's too much.

Re: [GOOS] Presenter-first design

rpin...@gmail.com (Rick Pingry) — Sat, 18 May 2013 06:01:40 UT

Thanks Tor and Josué,

I really liked what you had to say. I also liked your statements on the
other thread about why, what, and how being more important than the
terminology.

When I first read what you wrote above, about only testing against stable
interfaces, my head did begin to spin a little. In one respect, I totally

Re: [GOOS] Presenter-first design

josuesan...@gmail.com (Josue Barbosa dos Santos) — Fri, 17 May 2013 13:52:57 UT

Hello Johnny,

I will try to explain how we do in my Job. We use ATDD + TDD. So to write
any code you need a failing acceptance test that was validated by the
business. So in your example, yes we write the 11 acceptance tests (ATs).
The ATs serve to us as DOCUMENTATION too. I think the documentation part of