TDD == buzzword. Everybody talks about it, recruiters in companies ask questions about it and then 5% of developers use it.
The main reason of that state is that everybody talks about the TDD in the context of the modular unit testing. And 95% of developers do not have enough time to create isolated unit tests for each class. Most companies do integration testing without detailed unit tests for each class. Developers usually create test covering loading of the Spring context, Hibernate mappings and writing to HSQL database. One test covers many classes.
Also designing tests for each class eventually requires a lot of planning and lots of time to implement all the tests (i.e. money). This is good for Motorola, Google or NASA, but not for avarage business-oriented company. Most companies don't need 10000% test coverage - 80% covereage of crucial system areas is fair enough.
However I still find TDD amusing - I simply use it for acceptanace testing. Before I start to implement the core business code I create acceptance test for the entire requested functionality (front-end with Selenium, back-end services with Spring test utils, Web Services with SOAP-UI etc.). When my tests pass I can deliver the product to QA for further testing. My acceptance tests tell me that my job is done (and provide regression for future changes). And I don't have to think about that should I implement next - test failures tell me that. The important thing however is that I do not test deep internals of my code with separated tests without the explict reason.
Please be a good citizen and stop bother people with TDD-TO-EACH-OF-YOUR-TINY-CLASS bullshit. It just doesn't work that way.
"Also designing tests before implementation for each class for entires system requires a lot of planning and lots of time to implement all the tests (i.e. money)"
ReplyDeleteyes, probably but this has nothing to do with TDD. Designing tests BEFORE class implementation (not to say anything about the entire system!) is definitely not TDD approach.
AFAIK TDD cycle starts with the creation of the test. And before you create something you actually need to design it. Correct me if I'm wrong or maybe we're talking about different TDDs.
ReplyDeleteor maybe we understand designing differently ;) What you suggest here smells like big up front design ("designing tests before implementation for each class for entire system").
ReplyDeleteIn TDD development is DRIVEN by tests (as it says). You do not design too much up front. For sure you don't design tests for each class!
Maybe what you are describing here is kind of Microsoft way of TDD (no offence):
http://butunclebob.com/ArticleS.UncleBob.MsTdd
In sentence "designing tests before implementation for each class for entire system" I that understand you have to design each test before you start writing the class it refers to. But of course you don't have to design all these tests before you start implementing the first class of your project :)
ReplyDeleteI'll try to rephrase this ambiguous sentence. Thanks for pointing it out.