Despite having less users than I can count on one hand (unless there are silent users out there), Firmant is what I would consider a well-tested application.
Firmant has always put emphasis on rigorous testing of the code. As of right now 100% of the test package code runs each time all 211 tests are run. Each time the tests are run, 70% of the firmant package code is executed as well. All told this is a whopping 86% code coverage.
Let me say right now that I'd like to make this number higher.
Much of the code surrounding views is heavily untested, especially for comments. Before I attempt my next refactor, I hope to achieve 95% code coverage and maintain it through the code refactor. It is my hope that the time put into unit test creation will be more than made up for by not having to track down (or waste time on) bugs that could be prevented.
Testing Strategy
Firmant is a highly modular application. Tests are written to a particular interface, and then each implementation of an interface can easily take advantage of a thorough, already written test suite. In general it is only necessary to override the setUp and tearDown methods of test classes.
It takes exactly 100 lines of code to invoke the roughly 1300 lines of test code for the atom backend. Much of this is boilerplate I hope to be able to further reduce (Python is nice for doing this).
Why are these tests written like this? If some day someone wishes to write a CouchDB, MySQL, PostgreSQL or other backend, they can rely upon a test suite to ensure that most corner cases in their code are properly covered so that it can seemlessly be changed with the default Atom interface.
Porting Firmant
Firmant's test suite also makes it relatively easy to maintain several platforms at once without having to develop on all of them. FreeBSD, CentOS, Debian, and Fedora all should work without me having to develop on all these platforms. I need only to run the tests occasionally and verify that all pass.
I've found that CentOS provides the most information about non-portable Python code. CentOS is the only distribution I listed that still is defaulting to Python2.4. Debian is on 2.5 while FreeBSD generally tends to 2.6. From what I've heard, Fedora may go 3.0 sooner than the rest. I'll cross that line when it comes.
:wq