[cowiki-dev] Unit Testing
PAUL HANCHETT <[email protected]>
| Newsgroups | gmane.comp.php.cowiki.devel |
|---|---|
| Message-ID | <[email protected]> |
OK team, here is an improvement we can make in our process! I freely
admit that my style is *not* test /first/ but it sure is test soon!
Automated tests take a bit of time to develop, but the payback to the
project is tremendous. We need to do it, ***all*** of us!
Archie Campbell wrote:
> Crunch time: will it be faster to create unit tests for other
> processing, or rely on eyeball scrapes of test documents?
>
> Only you can tell.
The only time an eyeball scrape will be faster if you are writing code
that will be immediately thrown away. Really! For the most part,
writing unit test shouldn't take any longer than debugging the same code
and it produces the same effect, only for longer!
Unit tests should be written by the author of new code, and are updated
as needed by code maintainers. This ensures that once a test is written
it stays current. If a bug is discovered a unit test is created to
demonstrate the bug, then the source is fixed to correct the problem.
The test remains to perform automatic regression testing. (Having the
original author write the first unit tests ensures that the code is
/testable/, which is a key idea.)
From experience on previous projects: Unit tests are guaranteed to
save time on the project for _everyone_!
* The author saves time because his code is quick to test. He knows
what is broken and how. The code-test-fix cycle becomes
dramatically faster.
* Others save time, because they aren't given broken code to use.
Well done test cases become examples of how to use the module.
Everyone can see what functionality has been tested and what has not.
* The project saves time because many bugs are caught closer to the
time they are created, before being distributed across the project.
* It becomes (relatively) easy to refactor code because code that
passes the same unit tests "fits" the design of the system.
Limitations-- Obviously Unit Tests won't catch all problems. But the
majority of problems can be caught by Unit Testing
Here's some reading on the topic, tackle these in the order I've given
them... :
Test First Programming (Microsoft PPT)
<http://benjaminm.net/content/binary/Test%20First%20Programming.ppt>
Dive Into Python, Chapter 13 -- Unit Testing,
<http://diveintopython.org/unit_testing/index.html> Dive Into
Python, Chapter 14 -- Test-First Programming
<http://diveintopython.org/unit_testing/stage_1.html>
Design Principles in Test First Programming
<http://www.objectmentor.com/resources/articles/DesignPrin.pdf>
It's harder testing GUI issues, but we can easily test the functionality
behind the GUI. Not all code is easily testable; we should test where
it makes sense (parser, templates, database, configuration as examples).
Paul