A few facts that I didn't get to fit into the article:
- We have ~1.6x as much test code as we have code being tested.
- Our unit test suite takes < 5 seconds to run. Our system test suite takes < 60 seconds.
- We use Hudson for continuous integration
- The hardest part with TDD for us was reaching 1.0 as you always feel like it would be "faster" to stop testing.
- We usually don't go around refactoring stuff just because we can. In fact we usually feel more confident building upon existing stuff since we have tests that are saying it works.
And it goes without saying, feel free to ask me anything : ).
I have written a library called gently. This library lets you define a series of expected function calls spawning multiple objects (since overall order is important to us).
Whenever you define such an expected call, gently returns a closure that you can use to inject this expectation in the right place.
From my understanding this is hybrid between Mocking (where you have an object with an expected call / state sequence), and Stubbing (where you have various pre-recorded answers to function calls).
But generally I found the semantics of the various TDD methodologies very difficult to translate into actual code. That's why I'm using as little abstraction as possible.
- We have ~1.6x as much test code as we have code being tested.
- Our unit test suite takes < 5 seconds to run. Our system test suite takes < 60 seconds.
- We use Hudson for continuous integration
- The hardest part with TDD for us was reaching 1.0 as you always feel like it would be "faster" to stop testing.
- We usually don't go around refactoring stuff just because we can. In fact we usually feel more confident building upon existing stuff since we have tests that are saying it works.
And it goes without saying, feel free to ask me anything : ).