|Version 60 (modified by 14 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.
Behaviour-Driven Development takes this further to focus on the Specification rather than the Verification using something like pyspec or PyFITto provide testable specs:
There are a huge number of Testing Tools available to cover the various parts of the Testing process:
A community available for assistance:
Testing that Developers should be doing:
Unit Tests (must do)
Building the Code Right
- DocTest - inline with code: Agile Documentation
- DocTests for HTML apps (good since in-process hence can capture errors): http://agiletesting.blogspot.com/2006/04/in-process-web-app-testing-with-twill.html
- Uses wsgi_intercept: http://code.google.com/p/wsgi-intercept/
- Web2Py supports running doctests on Controllers from the admin UI, e.g.: http://127.0.0.1:8000/admin/default/test/sahana/default.py
- dutest - DocTest UnitTest integration (includes HTML-aware output checkers such as lxml.doctestcompare.LHTMLOutputChecker)
- UnitTest (formerly PyUnit)
- Nose - a discovery-based unittest extension
- Webunit - adds supports for HTTP GET/POST testing to unittest
- WebTest - CherryPy's extensions to unittest
Whenever a commit is made it should be checked to see that it doesn't break anything
- Patch Queue Manager - integrates with Bzr
- Bitten - integrates with Trac
Alternate options which could be investigated:
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 as part of Acceptance:
Boundary Testing (should do)
Building the Right Code
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.
Sahana is a Web-based application, so testing should be from browser perspective:
Functional tests can be written using:
- Selenium & Twisted: http://agiletesting.blogspot.com/2005/03/web-app-testing-with-python-part-2.html
- A lot of Selenium-related articles: http://vallista.idyll.org/~grig/articles/
- discussion on using Selenium with Web2Py: http://groups.google.com/group/web2py/msg/d8c9fd6008029f6b
- Mechanize - library for programming website browsing
- Twill is built on Mechanize
- zope.testbrowser is built on Mechanize (& not Zope-specific)
- MaxQ: http://agiletesting.blogspot.com/2005/02/web-app-testing-with-python-part-1.html
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 our functionality:
- UI Guidelines - comments on UI issues in Sahana2
- Are we XHTML 1.0 compliant?
Whilst the Web2Py framework is fast, we should check that we're not doing anything stupid to slow it down:
How many simultaneous users can the system support?
If extreme load is applied to the application, does it recover gracefully?
- Tools above but using more extreme parameters parameters
Whilst the Web2Py framework is secure by design, we should validate this:
Things developers can do to reduce risks:
Sahana 2 Links: http://wiki.sahana.lk/doku.php?id=dev:home#design_and_development_guides
- Regression tests.pdf (482.2 KB ) - added by 13 years ago.
) - added by 13 years ago.
Source for the PDF
) - added by 12 years ago.
) - added by 12 years ago.
Interactive Wrapper for Selenium
Download all attachments as: .zip