Unit Testing Proposal
Document Actions
Submitted by
ew2.
on 2008-06-26 11:18.
As we move toward having more outside development, automated unit tests could help keep our code in top shape.
Unit Testing
As we move toward having more outside development, automated unit tests could help keep our code in top shape.
What is a unit test?
- It is a test of a single component within an application
- Tests the "happy path" through a class or component
- It is usually implemented using a test framework which helps make them easy to implement
- The use of a framework makes them easy to automate and makes them repeatable
- Once it’s written, it lives as part of the code base.
- Any developer can run it.
Why should we unit test?
- Unit tests encourage more concise and compact code. Your code must be testable.
- Unit tests give inexperienced developers a way to verify that their changes did not break the current code
- Provide an easy way to verify refactoring which is essential to keeping a code base alive.
- They help find defects earlier when they are cheaper and easier to fix
- Running an automated build system, such as Bitten, on our development code can provide a snapshot of the quality of our development efforts
Arguments against unit tests
- They are time consuming to create - they do take time to create, but the trade off of easy testing in the future makes it worth the effort
- They don't really prove the code will work - this is correct,. They only provide a test on a certain path of functionality, but the testing is happening at a low level so any defects found are easier to fix
- I know what I am doing. I don't need a unit test - If you think this way, then you need to look at the fact that the unit test is for those that work on the code after you. They might not be as knowledgeable or experienced.
Unit test guidelines
There are many schools of thought on unit testing. These are some guidelines I have found helpful in the past.- Do not try to test every method
- Test the likely path of the code (public methods)
- Keep dependencies to a minimum
- If there are dependencies, provide setup code as part of the test
- Use mock objects where applicable
- Write code with test in mind or write test first
- I think this is key. It causes you to think and plan before or while writing code.
Problems with unit tests in Plone/Zope
- How to test py files used in templates? I don't think we can
- How to test functions outside of classes? Some are called by classes, so that could test them. Some are called in several places under different contexts which might be a problem.
- UI and classes are tightly coupled. Does this limit what can be unit tested?
- RhaptosCollection
- Collection
- Archetypes
- ArchetypeTestCase
- Schema created outside of function or class
- Printing
- PyUnit test
- Extended classes: CollectionBase and CollaborationManager
- ContentPointer, PublishedContentPointer, AsyncPrint
- How to test?
Unit Testing XSLT
Posted by
cbearden
at
2008-06-30 13:48
I haven't looked too much into unit testing for XSLT, but here are a few resources. I haven't had a chance to examine them in detail or to try them out.
Jeni Tennison (acknowledged XSLT expert) created unit-testing.zip, a Java package designed to work with Saxon >= 8.4b for unit testing stylesheets (http://www.jenitennison.com/xslt/utilities/unit-testing/);
Eric van der Vlist (acknowledged XML expert) created XSLTUnit, an XSLT-based system for XSLT unit tests (http://xsltunit.org/);
Jez Higgins gave a talk at a programmer's conference in 2005 on using XSLTUnit (http://www.jezuk.co.uk/accu2005/xslttesting/slide-1.html).
Jeni Tennison (acknowledged XSLT expert) created unit-testing.zip, a Java package designed to work with Saxon >= 8.4b for unit testing stylesheets (http://www.jenitennison.com/xslt/utilities/unit-testing/);
Eric van der Vlist (acknowledged XML expert) created XSLTUnit, an XSLT-based system for XSLT unit tests (http://xsltunit.org/);
Jez Higgins gave a talk at a programmer's conference in 2005 on using XSLTUnit (http://www.jezuk.co.uk/accu2005/xslttesting/slide-1.html).
BTW I am a big fan of unit tests. In Extreme Programming, one would write unit tests for every development cycle iteration, with the unit test being the success criteria for cycle completion. In action, this usually means that unit tests with the corner cases will force the developer to write a more complete implementation for the get-go, which should shorten the development cycle.