[GOOS] Just Searls' screencast: My favorite way to TDD

[philip schwarz]

http://blog.testdouble.com/posts/2015-09-10-how-i-use-test-doubles.html

GOOS is on the list of things referenced by the video series.

From the synopsis:

One topic that comes up often is the role of mock objects in testing,
particularly when practicing test-driven development. There are a lot of
forceful generalizations out there ("beware of over-mocking!", "only mock
what you own!", "only mock external systems you don't own!"), but taken
alone they don't do very much to explain when test doubles should be used
and when they shouldn't. I have a pretty good idea why that is.
The reason is that there are two schools-of-thought when it comes to TDD as
a productivity workflow. On one hand: Detroit-school TDD, the simpler
red-green-refactor workflow. On the other: London-school TDD, which makes
use of test doubles to direct the design of systems.
This video series explores the lesser known latter school, using a
technique that I've come to call Discovery Testing. We'll start with the
background needed to make sense of why the tooling and terminology we use
about testing is so overloaded, then use an ambitious approach to Conway's
Game of Life as an example problem to work through together, one test at a
time.

[Pietro Di Bello]

Hi Philip,
Do you watch the videos? What do you think?

I watched all the video series: the first one, which was mainly devoted to
introduce the two schools of TDD (Detroid or "classic" and London or
"mockist"), is fairly good and complete, even if some statements sounds
quite odd to me (e.g. with the "mockist" style you end up doing less
refactoring...).
The following three videos shows Justin's take on the Game Of Life, using
TDD with mock objects at the higher level of abstractions and ending with a
classical TDD on the lowest levels.
In the end I don't like much his way of using mocks and doing TDD, seems
too confusing, error prone and taking too big steps.
BTW I think it's interesting to watch those videos, and I appreciate
Justin's honesty in showing all his process, with all the hesitations and
false starts that we all know and experienced.

Thanks,


✎ Pietro Di Bello <http://about.me/pietrodibello>
.: XPeppers.com <http://www.xpeppers.com> :.


On Sat, Sep 12, 2015 at 7:01 AM, philip schwarz <

Post by philip schwarz
http://blog.testdouble.com/posts/2015-09-10-how-i-use-test-doubles.html
GOOS is on the list of things referenced by the video series.
One topic that comes up often is the role of mock objects in testing,
particularly when practicing test-driven development. There are a lot of
forceful generalizations out there ("beware of over-mocking!", "only mock
what you own!", "only mock external systems you don't own!"), but taken
alone they don't do very much to explain when test doubles should be used
and when they shouldn't. I have a pretty good idea why that is.
The reason is that there are two schools-of-thought when it comes to TDD
as a productivity workflow. On one hand: Detroit-school TDD, the simpler
red-green-refactor workflow. On the other: London-school TDD, which makes
use of test doubles to direct the design of systems.
This video series explores the lesser known latter school, using a
technique that I've come to call Discovery Testing. We'll start with the
background needed to make sense of why the tooling and terminology we use
about testing is so overloaded, then use an ambitious approach to Conway's
Game of Life as an example problem to work through together, one test at a
time.
--
---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Serkan Camurcuoglu]

I have watched the first 2 episodes yet, and I will watch the remaining 2
for sure.

These are the important points I've seen so far:

- He starts the process by thinking first, going back to the drawing
board and laying out the value objects and other important classes at the
beginning
- He uses some sort of command objects for business logic and names them
in a VerbNoun style (e.g. SimulatesConway instead of ConwaySimulator)
- He says that the tests which use mocks to test the interaction between
objects don't have much regression value
- He says that he prefers rewriting a small group of interacting objects
(including their associated tests) instead of refactoring when a larger
change needs to be done

I'm really happy with what I've seen so far, because although he has
selected a toy problem (Conway) he makes it seem like a bigger project that
is more similar to real life projects.

Although he calls his process "Discovery Testing", I like the idea of
thinking through the problem first and laying out major components before
writing the test. This seems at odds with ideas like "TDD drives good
design by itself" and transformation priority premise (which I understand
as "code happens automagically while you TDD, you don't have to think at
all"), but it's obviously a more natural approach. If I recall correctly,
in the video Justin says that he designs a little up front because you can
create a mess even if you do TDD, and usually the refactor step is
forgotten in red-green-refactor.

Anyway, for people like me who are struggling and have not yet absorbed and
internalized TDD, such videos have incredible value. And it would be even
greater if more TDD advocates / proponents produced such videos, preferably
using non-trivial examples, maybe even with real-world concerns (!) like
databases, transactions, layers etc.


On Wednesday, September 16, 2015 at 12:45:14 AM UTC+3, Pietro Di Bello

Post by Pietro Di Bello
Hi Philip,
Do you watch the videos? What do you think?
I watched all the video series: the first one, which was mainly devoted to
introduce the two schools of TDD (Detroid or "classic" and London or
"mockist"), is fairly good and complete, even if some statements sounds
quite odd to me (e.g. with the "mockist" style you end up doing less
refactoring...).
The following three videos shows Justin's take on the Game Of Life, using
TDD with mock objects at the higher level of abstractions and ending with a
classical TDD on the lowest levels.
In the end I don't like much his way of using mocks and doing TDD, seems
too confusing, error prone and taking too big steps.
BTW I think it's interesting to watch those videos, and I appreciate
Justin's honesty in showing all his process, with all the hesitations and
false starts that we all know and experienced.
Thanks,
✎ Pietro Di Bello <http://about.me/pietrodibello>
.: XPeppers.com <http://www.xpeppers.com> :.
On Sat, Sep 12, 2015 at 7:01 AM, philip schwarz <

Post by philip schwarz
http://blog.testdouble.com/posts/2015-09-10-how-i-use-test-doubles.html
GOOS is on the list of things referenced by the video series.
One topic that comes up often is the role of mock objects in testing,
particularly when practicing test-driven development. There are a lot of
forceful generalizations out there ("beware of over-mocking!", "only mock
what you own!", "only mock external systems you don't own!"), but taken
alone they don't do very much to explain when test doubles should be used
and when they shouldn't. I have a pretty good idea why that is.
The reason is that there are two schools-of-thought when it comes to TDD
as a productivity workflow. On one hand: Detroit-school TDD, the simpler
red-green-refactor workflow. On the other: London-school TDD, which makes
use of test doubles to direct the design of systems.
This video series explores the lesser known latter school, using a
technique that I've come to call Discovery Testing. We'll start with the
background needed to make sense of why the tooling and terminology we use
about testing is so overloaded, then use an ambitious approach to Conway's
Game of Life as an example problem to work through together, one test at a
time.
--
---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
For more options, visit https://groups.google.com/d/optout.

[Matteo Vaccari]

Post by Serkan Camurcuoglu
I have watched the first 2 episodes yet, and I will watch the remaining 2
for sure.
- He starts the process by thinking first, going back to the drawing
board and laying out the value objects and other important classes at the
beginning
- He uses some sort of command objects for business logic and names
them in a VerbNoun style (e.g. SimulatesConway instead of ConwaySimulator)
- He says that the tests which use mocks to test the interaction
between objects don't have much regression value
- He says that he prefers rewriting a small group of interacting
objects (including their associated tests) instead of refactoring when a
larger change needs to be done
Hi Serkan,

I haven't taken the time to watch the videos, but what you describe looks a
lot like what Keith Braithwaite [0] describes as "Pseudo TDD":

1. Think of a solution
2. Imagine a bunch of classes and functions that you just know you’ll
need to implement (1)
3. Write some tests that assert the existence of (2)
4. Run all tests and fail
5. Implement a bunch of stuff
6. Run all tests and fail
7. Debug
8. Run the tests and succeed

The way I have come to understand TDD so far, is more like

1. list all the *scenarios* I have to implement (the famous to-do list)
2. pick a scenario and write a test for it
3. implement very quickly
4. refactor to remove duplication
5. goto 2

It's the recipe in the original TDD book. It works. Perhaps it takes
years to realize that it's really that simple (it took me years in fact).
For instance, it took me years to convince myself that scraps of paper on
the wall are much better than Jira to help a team coordinate itself. It
was written in the book to use bits of paper, but I did not really believe
it.

Mocks helps you expecially in step 3; the mocks allow you to write a test
quickly, by focusing on a single aspect of the problem and delegating to
other objects that do not exist yet. This is also a big part of how design
"emerges".

TDD has a nice rhythm; you do the red-green-refactor many times in half an
hour. It's productive. "Pseudo TDD" does not have this rhythm; you spend
a lot of time with the red bar, debugging a preconceived design. It's
tiring.

Matteo

[0] http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/

[Serkan Camurcuoglu]

Hi Matteo,
"TDD as if you meant it" is a very well known article in these circles, and
I'm pretty sure Justin knows about it. In the video he mentions that he
does not apply TDD exactly as "preached".

The classic TDD workflow that you (and every other TDD advocate I know of)
are describing sounds really nice, but I haven't been able to achieve this
workflow myself.

It would be great if you could also make a screencast to demonstrate your
workflow to us in a non-trivial project and save us the years that you've
spent getting the gist of TDD.

Regards,

Post by Matteo Vaccari

Post by Serkan Camurcuoglu
I have watched the first 2 episodes yet, and I will watch the remaining 2
for sure.
- He starts the process by thinking first, going back to the drawing
board and laying out the value objects and other important classes at the
beginning
- He uses some sort of command objects for business logic and names
them in a VerbNoun style (e.g. SimulatesConway instead of ConwaySimulator)
- He says that the tests which use mocks to test the interaction
between objects don't have much regression value
- He says that he prefers rewriting a small group of interacting
objects (including their associated tests) instead of refactoring when a
larger change needs to be done
Hi Serkan,

I haven't taken the time to watch the videos, but what you describe looks
1. Think of a solution
2. Imagine a bunch of classes and functions that you just know you’ll
need to implement (1)
3. Write some tests that assert the existence of (2)
4. Run all tests and fail
5. Implement a bunch of stuff
6. Run all tests and fail
7. Debug
8. Run the tests and succeed
The way I have come to understand TDD so far, is more like
1. list all the *scenarios* I have to implement (the famous to-do list)
2. pick a scenario and write a test for it
3. implement very quickly
4. refactor to remove duplication
5. goto 2
It's the recipe in the original TDD book. It works. Perhaps it takes
years to realize that it's really that simple (it took me years in fact).
For instance, it took me years to convince myself that scraps of paper on
the wall are much better than Jira to help a team coordinate itself. It
was written in the book to use bits of paper, but I did not really believe
it.
Mocks helps you expecially in step 3; the mocks allow you to write a test
quickly, by focusing on a single aspect of the problem and delegating to
other objects that do not exist yet. This is also a big part of how design
"emerges".
TDD has a nice rhythm; you do the red-green-refactor many times in half an
hour. It's productive. "Pseudo TDD" does not have this rhythm; you spend
a lot of time with the red bar, debugging a preconceived design. It's
tiring.
Matteo
[0] http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/

[Matteo Vaccari]

I could do that (what would be a sufficiently non-trivial project for
you?). We could also do something else: you could post some problem that
is giving you trouble, and how you tried to TDD it, and I or others could
perhaps point out what you could do differently.

The videos by Kent Beck and J.B. Rainsberger that were mentioned in this
list recently would probably be of more value to you than any video I could
do.

If you really want to check for yourself how I do TDD, you could check out
this: http://leanpub.com/tddforandroid . It's very very rough and
incomplete and the quality cannot be compared by a long shot to JB's and
Kent Beck's material, so feel free to get it for free.

Ah, and one more thing about the "trivial example" objection. Well written
code does tend to look trivial. I read the Money example in "TDD By
Example" and I thought "yes, that's a very simple example". And this is
precisely the point: TDD leads to simple code. The equivalent
functionality in everyday Java enterprise code would probably look much
more complicated.

I'm finding that because TDD pushes you towards small things, and because
of some very good mentoring in the late 1990's, everything I write is tiny
and looks like a toy problem. Many times, I've had those who don't
understand TDD say things like "Why did you bother to write tests for all
this? It's all too simple to bother.", which has some resonance with "Test
Everything That Could Possibly Break", where there is errr
 nothing that
could possibly break, because it's all so simple (take that last bit with
some humour please).
And yet, when I do write the code without TDDing it, although I maintain
the smallness and the simplicity, I often find defects.
So my answer to this issue is that ALL well factored code has that "toy
problem" quality to it, and indeed that is what should be aspired to. If
you only aim to TDD (or test after the fact) the complex stuff, then I can
pretty much guarantee that you will get a lot of complex stuff, most of
which won't work. And the anecdotal evidence we have for this is
overwhelming (in the financial sector in which I tend to work).
Lance Walton
http://groups.google.com/group/lonely-coaches-sodality/msg/368d125e4487d9fb
Hi Matteo,
"TDD as if you meant it" is a very well known article in these circles,
and I'm pretty sure Justin knows about it. In the video he mentions that he
does not apply TDD exactly as "preached".
The classic TDD workflow that you (and every other TDD advocate I know of)
are describing sounds really nice, but I haven't been able to achieve this
workflow myself.
It would be great if you could also make a screencast to demonstrate your
workflow to us in a non-trivial project and save us the years that you've
spent getting the gist of TDD.
Regards,

Post by Matteo Vaccari

Post by Serkan Camurcuoglu
I have watched the first 2 episodes yet, and I will watch the remaining
2 for sure.
- He starts the process by thinking first, going back to the drawing
board and laying out the value objects and other important classes at the
beginning
- He uses some sort of command objects for business logic and names
them in a VerbNoun style (e.g. SimulatesConway instead of ConwaySimulator)
- He says that the tests which use mocks to test the interaction
between objects don't have much regression value
- He says that he prefers rewriting a small group of interacting
objects (including their associated tests) instead of refactoring when a
larger change needs to be done
Hi Serkan,

I haven't taken the time to watch the videos, but what you describe looks
1. Think of a solution
2. Imagine a bunch of classes and functions that you just know you’ll
need to implement (1)
3. Write some tests that assert the existence of (2)
4. Run all tests and fail
5. Implement a bunch of stuff
6. Run all tests and fail
7. Debug
8. Run the tests and succeed
The way I have come to understand TDD so far, is more like
1. list all the *scenarios* I have to implement (the famous to-do list)
2. pick a scenario and write a test for it
3. implement very quickly
4. refactor to remove duplication
5. goto 2
It's the recipe in the original TDD book. It works. Perhaps it takes
years to realize that it's really that simple (it took me years in fact).
For instance, it took me years to convince myself that scraps of paper on
the wall are much better than Jira to help a team coordinate itself. It
was written in the book to use bits of paper, but I did not really believe
it.
Mocks helps you expecially in step 3; the mocks allow you to write a test
quickly, by focusing on a single aspect of the problem and delegating to
other objects that do not exist yet. This is also a big part of how design
"emerges".
TDD has a nice rhythm; you do the red-green-refactor many times in half
an hour. It's productive. "Pseudo TDD" does not have this rhythm; you
spend a lot of time with the red bar, debugging a preconceived design.
It's tiring.
Matteo
[0] http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/
--

---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Pietro Di Bello]

Hi Serkan
I'd recommend watching these videos, at least the first two of them,
because that forces you to think and reflect: where is your TDD process
similar to the one described by Justin? Where it differs, and why? Are you
used to take smaller steps, or bigger? How do you feel when you change the
application code with a red bar? What kind of strategies do you follow to
name things? These and more questions should emerge while you watch the
videos, and should trigger interesting reflections about *your own* TDD
process.
Pietro

Post by Serkan Camurcuoglu
I have watched the first 2 episodes yet, and I will watch the remaining 2
for sure.
- He starts the process by thinking first, going back to the drawing
board and laying out the value objects and other important classes at the
beginning
- He uses some sort of command objects for business logic and names
them in a VerbNoun style (e.g. SimulatesConway instead of ConwaySimulator)
- He says that the tests which use mocks to test the interaction
between objects don't have much regression value
- He says that he prefers rewriting a small group of interacting
objects (including their associated tests) instead of refactoring when a
larger change needs to be done
I'm really happy with what I've seen so far, because although he has
selected a toy problem (Conway) he makes it seem like a bigger project that
is more similar to real life projects.
Although he calls his process "Discovery Testing", I like the idea of
thinking through the problem first and laying out major components before
writing the test. This seems at odds with ideas like "TDD drives good
design by itself" and transformation priority premise (which I understand
as "code happens automagically while you TDD, you don't have to think at
all"), but it's obviously a more natural approach. If I recall correctly,
in the video Justin says that he designs a little up front because you can
create a mess even if you do TDD, and usually the refactor step is
forgotten in red-green-refactor.
Anyway, for people like me who are struggling and have not yet absorbed
and internalized TDD, such videos have incredible value. And it would be
even greater if more TDD advocates / proponents produced such videos,
preferably using non-trivial examples, maybe even with real-world concerns
(!) like databases, transactions, layers etc.
On Wednesday, September 16, 2015 at 12:45:14 AM UTC+3, Pietro Di Bello

Post by Pietro Di Bello
Hi Philip,
Do you watch the videos? What do you think?
I watched all the video series: the first one, which was mainly devoted
to introduce the two schools of TDD (Detroid or "classic" and London or
"mockist"), is fairly good and complete, even if some statements sounds
quite odd to me (e.g. with the "mockist" style you end up doing less
refactoring...).
The following three videos shows Justin's take on the Game Of Life, using
TDD with mock objects at the higher level of abstractions and ending with a
classical TDD on the lowest levels.
In the end I don't like much his way of using mocks and doing TDD, seems
too confusing, error prone and taking too big steps.
BTW I think it's interesting to watch those videos, and I appreciate
Justin's honesty in showing all his process, with all the hesitations and
false starts that we all know and experienced.
Thanks,
✎ Pietro Di Bello <http://about.me/pietrodibello>
.: XPeppers.com <http://www.xpeppers.com> :.
On Sat, Sep 12, 2015 at 7:01 AM, philip schwarz <

Post by philip schwarz
http://blog.testdouble.com/posts/2015-09-10-how-i-use-test-doubles.html
GOOS is on the list of things referenced by the video series.
One topic that comes up often is the role of mock objects in testing,
particularly when practicing test-driven development. There are a lot of
forceful generalizations out there ("beware of over-mocking!", "only mock
what you own!", "only mock external systems you don't own!"), but taken
alone they don't do very much to explain when test doubles should be used
and when they shouldn't. I have a pretty good idea why that is.
The reason is that there are two schools-of-thought when it comes to TDD
as a productivity workflow. On one hand: Detroit-school TDD, the simpler
red-green-refactor workflow. On the other: London-school TDD, which makes
use of test doubles to direct the design of systems.
This video series explores the lesser known latter school, using a
technique that I've come to call Discovery Testing. We'll start with the
background needed to make sense of why the tooling and terminology we use
about testing is so overloaded, then use an ambitious approach to Conway's
Game of Life as an example problem to work through together, one test at a
time.
--
---
You received this message because you are subscribed to the Google
Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.