By: Christoph Steindl
What is Test-Driven Development?
In principle, it is just about writing the test before the
But in consequence, it leads the developer to
.. first think about “how to use” the component (why do we need
the component, what’s it for?)
.. and only then about “how to implement”.
So, it’s a testing technique as well as a design
.. It results into components that are easy to test.
.. It results into components that are easy to enhance and adap
In the end, there is no code without a test.
The developer can tell at any time
.. whether everything still works as it should, or
.. what exactly does no longer work as it once did.
If you intend to test after you‘ve developed the system, you won‘t have the
time for testing.
.. Write the tests before the code!
If things get complicated, you might fear that „the system“ doesn‘t work.
.. Execute the tests and get positive feedback (everything still works) or
get pointed to the bit that does not / no longer work.
If you‘re overwhelmed by the complexity, you get frustrated.
.. Start with the simplest thing and proceed in tiny steps!
If you don‘t have tests for the code, you shouldn‘t use it / ship it.
.. This can‘t happen if you write the test first (so you reach better test
coverage than with functional tests).
If performance is only considered late, you won‘t be able to just „add a little
more performance“ to the system.
.. Re-use unit tests for performance tests even during development and
don‘t start with performance tests late in the project!
The test is the executable specification.
.. You start thinking about the goal first, then about the possible
.. You understand the program‘s behavior by looking at the tests. The
tests tell you more than just an API description, they show the
dynamics, how to use the API.
You develop just enough.
.. You get to the goal as quick as possible.
.. You don‘t develop unnecessary code.
.. There is no code without a test.
.. There is no test without a user requirement.
Once you get one test working, you know it is working now and
.. You use the tests as regression tests.
The tests give us the courage to refactor.
.. You can prove that everything still works after the refactoring by simply
executing the tests.
It‘s more fun that way, it reduces fear.
Don‘t start with objects (or design, or ...), start with a
.. Write new code only if an automated test has failed.
.. First think of the goal, the required functionality.
.. Then think of the perfect interface for that operation (from the
outside, black-box view).
Run the test often – very often.
.. To determine whether you‘ve reached the goal.
.. To catch any bugs that have crawled back in.
Make little steps (during coding and refactoring)
.. So little that you feel comfortable with them.
.. Make them larger if you feel.
.. Make them smaller if you don‘t proceed with your expected
... to read more articles, visit http://sqa.fyicenter.com/art/