Version 32 (modified by Fran Boon, 13 years ago) ( diff )




"A bug is a test case you haven't written yet"
"Unit Tests allow merciless refactoring"

Test-Driven Development is a programming styles which says that you 1st write your test cases (from the specs) & then proceed to make them pass.

There are a huge number of Testing Tools available to cover the various parts of the Testing process:

Testing that Developers should be doing:

Unit Tests (must do)

These should be written by the developers

Continuous Integration

Whenever a commit is made it should be checked to see that it doesn't break anything

Alternate options which could be investigated:

Regression Testing

Fired by dev after certain number of changes or whenever they like.


As well as writing DocStrings in all functions, we can generate an overall API using:

If writing a separate manual then we can use:

Testing that Testers should be doing:

Boundary Testing (should do)

Checks functionality of modules against specs.

This sees the application as a black box & so the same tests could be run here against both the Python & PHP versions, for instance.

Functional tests can be written using:

This is done by the Testers who accept the Code as a result.

Integration Testing (good thing)

We depend on various 3rd-party components so we need to ensure that as these components are upgraded this doesn't break any of out functionality:

  • Web2Py
    • CherryPy
    • SimpleJSON
  • T2
  • OpenLayers
  • jQuery
  • Ext

Usability Tests


  • Are we XHTML 1.0 compliant?
  • Are we usable without JavaScript?

Performance Tests

Whilst the Web2Py framework is fast, we should check that we're not doing anything stupid to slow it down:

Stress Tests

Security Tests

Whilst the Web2Py framework is secure by design, we should validate this:


Attachments (4)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.