This is a test.
Test Driven Development (TDD) is becoming quite a buzz word these days in the world of software engineering and development. It is something that came out of Agile development and Extreme programming practices. Many and more software houses and teams are adopting TDD. Of course, there are many who do not agree with its concepts, either fully or partially. This article highlights some opinions in favor of and against it.
Basically, a programmer starts with writing some test cases with his expected result out of a software module. Obviously when he runs the test, it will fail because the module hasn’t actually been written at the other side. Then he moves along with writing the minimum code that will make the test succeed. This might just be a skeleton code that returns the data or somehow simulates the implementation of business logic. The next step would be to write the actual code that accomplishes it. Final step would be to refactor it, making it more maintainable and reusable.
According to “TDD is not about Testing”, TDD is a method of building the software with the functionality it actually needs and not with what the programmer thinks it probably would have. It might appear somewhat counterintuitive at the beginning, but it not only makes sense, it also quickly becomes a natural and elegant way to develop software.
Today there a lot of tools out there that assist a developer with TDD. Advanced IDEs such as Eclipse, Visual Studio has built in support for Unit testing frameworks such as JUnit for example along with extensive support for code generation to automatically write the skeleton classes and methods and have quite intuitive refactoring functionalities.
Many look at it as a way of driving the requirements early into the development and putting it on the table at the beginning itself in form of test cases. By writing the code minimum enough to satisfy the test cases, a programmer doesn’t over do any tasks and eventually sticking to the specifications and design. As it appears to me, even though TDD is not about ‘Testing’ in conventional sense, testing is an integral part of it, particularly the unit testing. It is the test cases that lay foundation for further development in TDD. The article at http://powersoftwo.agileinstitute.com/2011/11/five-key-ingredients-of-essential-test.html outline test as the first out of five essential ingredients for TDD.
However, even though it is an approach to build software with functionality it needs rather than what programmer thinks it should have, it the same programmer who will be writing the test cases. A single programmer or maybe even a couple of them (pair programming) will be able to think and writing only so much of possible use cases in form of test cases. The article “Unit testing vs. Beta testing” highlights a blog post of Wil Shipley and outlines following (taken directly from the article):
- While unit test cases can be written to as trivial level as possible, some bugs really don’t matter. If a bug exists but no user ever encounters it, do you care? If a bug exists but only one in ten thousand users ever encounters it, do you care? Even Joel Spolsky seems to agree in this point. Shouldn’t we be fixing bugs based on data gathered from actual usage rather than a stack of obscure, failed unit tests?
- A unit test simply verifies that something works. This makes it far, far too easy on the code. Real testers hate your code and will do whatever it takes to break it– feed it garbage, send absurdly large inputs, enter Unicode values, double-click every button in your app, etc.
- Users are crazy. Automated test suites are a poor substitute for real world beta testing by actual beta testers. Users are erratic. Users have favorite code paths. Users have weird software installed on their PCs. Users are crazy, period. Machines are far too rational to test like users.
The article ends with conclusion that unit testing, while is called testing, is not real testing. Real testing occurs when tested by a non-developer and mainly when it is shipped to the alpha or beta testers.
The most dangerous pitfall of automated tests or unit tests, in my opinion, is that if some tests fail then the programmer will work towards it, but the opposite is not true. When the tests appear green, it does not necessarily mean that the software has accomplished it goal. It could be a false positive.
While there will always be pros and cons of everything, TDD is certainly one of the proven methods that combines the best practices of an agile development. But because of the pitfalls it possesses, focusing too much only into it and prioritizing it or the unit tests over real testing would be foolish.