[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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.