CoUnit
Introduction
CoUnit is a unit testing framework for Cocoon applications.
It can be used to specify and execute unit tests for pipelines and stylesheets.
CoUnit is not meant for testing components written in Java; we have JUnit for that. It will also not help to test the web-frontend of your application; HttpUnit does a fine job in that realm. CoUnit helps you to test the bits in between: All the code that lives in the pipelines, transforming XML (SAX events). At the moment, it is particularly good at testing XSLT stylesheets, but Flowscript is not yet covered.
CoUnit can be used with Cocoon 2.1.6 and higher. If you need to use an earlier version of Cocoon, you will need to retrofit the MountTableTransformer from the Cocoon repository after 11 October 2004.
Unit testing, and test-driven development
Unit (and regression) testing has been one of the best practices in software development for a long time (I first came acress it in an article in Dr. Dobbs Journal , February 1997). More recently it has become popular as part of the eXtreme Programming method, where it has evolved into test-driven development. There are many good books and web sites about unit testing, which you should have a look at if you have never heard about these methods:
- JUnit - dedicated to software developers using JUnit or one of the other XUnit testing frameworks.
- TestDriven - promoting techniques, tools, and general good will in the test-driven community.
- Test Driven Development - a page at objectmentor.com
Unit testing is about testing your code at a fine level of granularity; a
single method or function. Regression testing extends this method by making a
set of unit tests repeatable and automated, thus giving you an instant picture
of the quality of your code.
Test-driven development takes this idea a step further, and demands that you do
not write tests to check your code after it has been written, but write
them before you write code, as part of the specification of what that
code is supposed to do. The development cycle now becomes:
- Write a test that specifies a tiny bit of functionality.
- Ensure the test fails. (You haven't built the functionality yet!)
- Write only the code necessary to make the test pass.
- Refactor the code, ensuring that it has the simplest design possible for the functionality implemented until now.
On a project, this should be done following these rules:
- After every change, run all tests.
- Refactor the code if a test fails.
- Only check-in the code if all tests succeed.
- When a bug is found, first write a test for it, then refactor the code.
- Tests are organized in ‘suites’ – groups of tests for a particular bit of
functionality.
There are many benefits to this approach, please see the references cited above.
Project resources
- Mailing lists: http://lists.cocoondev.org/mailman/listinfo
-
SVN:
http://svn.cocoondev.org/repos/counit
Frequently asked questions
Q: I get a NullPointerException trying to run unit tests, even those that
come with CoUnit.
A: You need to update Cocoon to version 2.1.6 or higher, or at least update the
MountTableTransformer to a version later than 11 October 2004.