Software QA FYI - SQAFYI

Test-Driven Development

By: Christoph Steindl

What is Test-Driven Development?
In principle, it is just about writing the test before the program.
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 technique
.. It results into components that are easy to test.
.. It results into components that are easy to enhance and adap

t. 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 implementations.
.. 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 forever.
.. 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 test.
.. 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 velocity

Full article...

Other Resource

... to read more articles, visit

Test-Driven Development