Have you been in cases where TDD increased development time?

Question

Hello everyone :)

I was reading http://stackoverflow.com/questions/2512504/tdd-how-to-start-really-thinking-tdd and I noticed many of the answers indicate that tests + application should take less time than just writing the application. In my experience, this is not true. My problem though is that some 90% of the code I write has a TON of operating system calls. The time spent to actually mock these up takes much longer than just writing the code in the first place. Sometimes 4 or 5 times as long to write the test as to write the actual code.

I'm curious if there are other developers in this kind of a scenario.

Answer 1

You don't have to achieve 100% code coverage. If a piece of code is a simple wrapper around an OS call, then there has to come a time that you assume that the OS call will do what it's supposed to do (ie. you don't need to call the simple wrapper).

Now, if you have complex logic around that OS call, then it would make sense to mock the os call and unit test the logic. Of course, if you have a good abstraction layer on top of the OS call, this wouldn't be hard.

You just have to focus your efforts on the pieces that give you the best bang for your maintenance buck

Answer 2

Unfortgunately, this is NOT language agnostic. In properly mockable languages (my experience is with Perl), mocking ANYTHING - including system calls - is, given a proper mocking library, VERY cheap, fast and easy.

Answer 3

In general, when people have the experience that TDD makes the time it takes to get a piece of work done take longer it is because they have an improper definition of "done" or of "piece of work." Typically these people believe in the myth of "code complete."

Anyone can bang out some code faster than they can bang out some code and some tests. However, typing is not really where the time goes. If you start measuring the whole time - from concept to deployment - that a whole feature - from soup to nuts - takes, you will stop having the experience of TDD "taking longer."

Also, the OS thing isn't that important, as Joel implies: mock out the OS so that you can text your complex uses of the OS calls but don't bother testing the OS unless you have a reason you need to call out an assumption as a test.

Answer 4

TDD isn't mocking. Sometimes, good TDD employs mocks, but plenty of TDD can be done without mocks, and if you're confronting too much mocking with your TDD, perhaps you need to go "old school" and write simpler tests.