Changes between Version 110 and Version 111 of DeveloperGuidelinesTesting


Ignore:
Timestamp:
08/08/11 21:13:52 (10 years ago)
Author:
Mike A
Comment:

Added section on writing tests with simple examples of both methods

Legend:

Unmodified
Added
Removed
Modified
  • DeveloperGuidelinesTesting

    v110 v111  
    6969 * simplification of integration testing (because all the parts are known to work, only interfaces between them need testing),
    7070 * better system design by:
    71  ** easing refactoring (changes can be more rapidly verified not to create new bugs),
    72  ** promoting refactoring (dividing units into testable pieces also creates more reusable pieces),
    73  ** standing in for specification documents (i.e. describing by example what the code needs to do).
     71   * easing refactoring (changes can be more rapidly verified not to create new bugs),
     72   * promoting refactoring (dividing units into testable pieces also creates more reusable pieces),
     73   * standing in for specification documents (i.e. describing by example what the code needs to do).
    7474
    7575Cons:
     
    115115'''Advice:'''
    116116
    117 One unittest.TestCase per unit (procedure, method or function). This makes test output easy to follow as it is what unittest expects. I.e. don't test several units in one TestCase.
    118 You can just use asserts instead of the cumbersome test.assertEquals etc. methods which often don't do what you need. nose can introspect the stack to make meaningful messages.
    119 Avoid inheritance trees with unittests as the unittest.TestCase isn't really designed for inheritance, more as a convenient place to put the tests.
    120 Break test methods up into smaller methods. Non-test code can be extracted out into external procedures/functions which are easier to reuse.
    121 Read the nose documentation regarding writing tests: [http://readthedocs.org/docs/nose/en/latest/writing_tests.html]
    122 Read this too: [http://ivory.idyll.org/articles/nose-intro.html]
     117* One unittest.TestCase per unit (procedure, method or function). This makes test output easy to follow as it is what unittest expects. I.e. don't test several units in one TestCase.
     118* You can just use asserts instead of the cumbersome test.assertEquals etc. methods which often don't do what you need. nose can introspect the stack to make meaningful messages.
     119* Avoid inheritance trees with unittests as the unittest.TestCase isn't really designed for inheritance, more as a convenient place to put the tests.
     120* Break test methods up into smaller methods. Non-test code can be extracted out into external procedures/functions which are easier to reuse.
     121* Read the nose documentation regarding writing tests: [http://readthedocs.org/docs/nose/en/latest/writing_tests.html]
     122* Read this too: [http://ivory.idyll.org/articles/nose-intro.html]
    123123
    124124=== Examples ===