DeveloperGuidelines

= Testing =
"A bug is a test case you haven't written yet" [[BR]]
"Unit Tests allow merciless [http://diveintopython.org/refactoring/refactoring.html refactoring]"

Test-Driven Development is a programming styles which says that you 1st write your test cases (from the [BluePrints specs]) & then proceed to make them pass.[[BR]]
Behaviour-Driven Development takes this further to focus on the Specification rather than the Verification using something like [http://www.codeplex.com/pyspec pyspec] or [http://pypi.python.org/pypi/PyFIT/0.8a2 PyFIT]to provide testable specs:
 * http://behaviour-driven.org
 * http://fitnesse.org/FitNesse.AcceptanceTests

There are a huge number of Testing Tools available to cover the various parts of the Testing process:
 * http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy
 * http://vallista.idyll.org/~grig/articles/
A community available for assistance:
 * http://lists.idyll.org/listinfo/testing-in-python
----
Testing that Developers should be doing:
== Unit Tests (must do) ==
Building the Code Right
 * http://diveintopython.org/unit_testing/index.html
These should be written by the developers
 * [http://www.python.org/doc/2.6/library/doctest.html DocTest] - inline with code: Agile Documentation
  * http://agiletesting.blogspot.com/2005/01/python-unit-testing-part-2-doctest.html
  * Web2Py supports running doctests on Controllers from the admin UI, e.g.: http://127.0.0.1:8000/admin/default/test/sahana/default.py

 * [http://docs.python.org/library/unittest.html UnitTest] (formerly [http://pyunit.sourceforge.net PyUnit])
  * http://agiletesting.blogspot.com/2005/01/python-unit-testing-part-1-unittest.html
  * [http://somethingaboutorange.com/mrl/projects/nose/ Nose] - a discovery-based unittest extension

== Continuous Integration ==
Whenever a commit is made it should be checked to see that it doesn't break anything
 * [https://launchpad.net/pqm Patch Queue Manager] - integrates with Bzr
 * [http://bitten.edgewall.org Bitten] - integrates with Trac
Alternate options which could be investigated:
 * http://buildbot.net/trac
 * http://cruisecontrol.sourceforge.net

== Regression Testing ==
Fired by dev after certain number of changes or whenever they like.
 * http://www.pycheesecake.org/
  * Case Study: http://pycheesecake.org/wiki/CleaningUpPyBlosxom
 * [http://www.logilab.org/857 PyLint]
 * http://docs.python.org/library/test.html

== Documentation ==
As well as writing !DocStrings in all functions, we can generate an overall API using:
 * http://epydoc.sourceforge.net
If writing a separate manual then we can use:
 * http://docutils.sourceforge.net
----
Testing that Testers should be doing:
== Boundary Testing (should do) ==
Checks functionality of modules against [BluePrints specs]: Building the Right Code

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:
 * [http://seleniumhq.org Selenium]
  * discussion on using Selenium with Web2Py: http://groups.google.com/group/web2py/msg/d8c9fd6008029f6b
 * [http://jakarta.apache.org/jmeter/ JMeter]
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 ==
 * [http://www.it.rit.edu/~jxs/development/Sahana/00_UI_Comments.html UI Guidelines] - comments on UI issues in Sahana2
=== Accessibility ===
 * 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:
 * http://groups.google.com/group/web2py/browse_thread/thread/cf5c5bd53bc42d49

== Stress Tests ==
 * http://tsung.erlang-projects.org/
 * Siege

== Security Tests ==
Whilst the Web2Py framework is secure by design, we should validate this:
 * http://mdp.cti.depaul.edu/examples/default/features
----
DeveloperGuidelines