development1Add my vote for this tag create new tag
, view all tags
Really the best way to write code is to write the tests first, and then write the code until the tests pass. The tests express the intent, and the code realises that intent. Some would argue that with good clear tests in place, no other documentation is required.

In reality, very few of us have the experience or the patience to fully realise this approach when writing code on our own, or for what we perceive as "non-critical" systems. However, there's a lot to be learnt from the approach that can help us write tests for our own code.

Here are some guiding principles learnt from writing tests for TWiki extensions (plugins, contribs, add-ons, ...).

  1. The BuildContribCookbook has a recipe "Making unit tests". Even if you do not (yet) build your extension with BuildContrib it might be wise to adopt this recipe with regard to the directory structure.
  2. Modularise your code into blocks that know as little as possible about the context they are called within. That means, avoid using globals wherever possible, pass in parameters instead, use OO techniques if you know what they are. Keep functions simple, and use simple functions to build up more complex blocks of code. Look for opprotunities to re-use code in the shared code area or CPAN rather than rewriting from scratch. Above all, avoid using globals wherever possible.
  3. Write short tests, each of which tests some simple aspect of the specification. In most cases you will write several test functions for each function/method you write.
  4. Don't write tests for conditions that cannot arise under the terms of the spec, but make sure you write tests for all realistic conditions that can arise.
  5. Focus on testing the external interface to the code under test, as that is what is going to be used.
  6. Remove context dependencies by writing test fixtures instead of calling TWiki code during tests. Test fixtures are blocks of code that implement ("spoof") the TWiki functions you would normally call, but in highly controlled circumstances. Fixtures are usually themselves loaded with debugging, and are often re-usable from test to test and from extension to extension.
  7. Familiarise yourself with the reusable test fixtures in test/unit/TWikiTestCase.pm and test/unit/TWikiFnTestCase.pm and use them, rather than writing new fixtures.
  8. Familiarise yourself with Test::Unit and use it.
  9. Maintain the shared fixtures; they are for everyone's benefit.
  10. Avoid using globals wherever possible. Using globals is the easiest way to introduce context dependencies into your extension, and make it much, much harder to test.

For an example of a plugin written and tested using all the above techniques, see the CommentPlugin.

See CategoryTesting for links to information on TWiki testing strategies.



According to the recipe "Making unit tests" in BuildContribCookbook, tests for extensions developed in SVN are in twikiplugins/MYPLUGIN/test/unit/MYPLUGIN/, which through pseudo-install are also moved or linked to =test/unit/MYPLUGIN.

-- HaraldJoerg, ThomasWeigert, CrawfordCurrie - 02 Dec 2006

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2006-12-03 - ThomasWeigert
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.