VirtualTam's bookmarks

  1. A collection of misc. resources: FLOSS, ecology, architecture...

  2. Python's built-in unittest module is quite cool, but a bit limited and way too verbose (read: it's quite not easy to incite developers to write unit tests)

    I'm currently looking for more dev-friendly solutions, the key points being:

    • writing test code should be easy and straight-forward -keep the focus on "what to test" instead of "how to transcribe a process to a test"
    • parallelization! -we, spoiled developers, should make good use of our way-too-many-cores build machines...
    • complete feature set!
      • we don't want to just run tests...
      • coverage reports (find dead/weak/untested code sections)
      • output formatting (JUnit-XML seems to be quite a common format out there)

    There seem to be 3 solutions in Python:

    • stock unittest + project-dependent customizations / test helpers
    • nosetests
    • py.test

    And 2 ways of gettings things done:

    • keeping things stock: no external dependency, project-specific implementation...
    • using a test framework: one more module in your (test) virtualenv, more concise tests, more features (// run, code coverage, etc.)

    Some links:

  3. Given your unittests are in the tests directory:

     1# run a specific test module
     2python -m unittest tests.<module>
     3 
     4# run a specific test suite
     5python -m unittest tests.<module>.<class>
     6 
     7# run a specific test
     8python -m unittest tests.<module>.<class>.<test>
     9 
    10# run tests matching a given pattern
    11python -m unittest discover -s tests -p <pattern>
    
  4. Includes support for Coverage, Xunit and other cool stuff ;-) Oh, and there is parallel testing, too \o/

    nosetests --with-coverage --cover-erase --cover-tests --cover-html --cover-html-dir=htmlcov --with-xunit --xunit-file=unit.xml

    via http://www.alexconrad.org/2011/10/jenkins-and-python.html

  5. Awesome thread! The topvoted comments show extremely good - yet simple - reasons to become a unit test maniac ;-)

    See also: