--
---
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.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.
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 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.
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.
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.