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

.: XPeppers.com :.

--

---
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 growing-object-oriente...@googlegroups.com.
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.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

[Matteo Vaccari]

On Thu, Sep 17, 2015 at 10:24 AM, Serkan Camurcuoglu <scamur...@gmail.com> wrote:

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

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,

[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 like very much this quote:

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

--

---
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 growing-object-oriente...@googlegroups.com.

[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

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

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 email to growing-object-oriente...@googlegroups.com.