aclark wrote: > > What I'm looking for: > > - Advice on what types of tests you'd expect to see. > > - Ideas to make testing "fun". >
I mainly find 2 kinds of tests handy: unit and integration. Unit tests are nice because they run fast (unlike any PloneTestCase-based tests) and tell you exactly where any problems are, assuming your units are small enough. Integration tests, meanwhile, are nice because you can run them against new versions of Plone and be pretty satisfied that your product still works. They usually give you just as much protection against regressions as unit tests, but the causes of failures are harder to uncover due to the bigger globs of stuff being tested at once. Integration tests are kind of a pain to write in Plone (or any IOC framework with sparse docs) because it takes time to figure out how to kick off your code in the same way Plone would. Most of my time writing integration tests is burned doing that, and it's not a lot of fun. Browsertests are a partial answer, but unfortunately there's a lot of information loss and markup dependence when you work up at that layer. I reserve them for hard-to-mock things like complicated multipage forms with cookies and junk dripping off the sides. The fun of testing comes from your newfound freedom to move and change things without having to manually retest it all. It saves time and removes a disincentive to improve code. Testing is sometimes jokingly referred to as a religion, but it's this practical time savings we're chasing, not a mindless dogma for the sake of itself. More test code isn't necessarily better, as it's still code that has to be understood and maintained; the key is to find the point where the tests save you more time than you put into them. Tests are there to serve you, not the other way around. To improve my chances at a good ROI (and fun!), I keep these rules of thumb in mind: * Write long-lived tests. They should be independent of implementation and encode only foundational assumptions so the tested code can be refactored and improved without invalidating them. * Branches are the devil. To give a really simple example, `return max(x, y)` is better than `if x > 0: return x: else: return y` because there's only one code path (within your code, anyway) to test. Fewer tests, coverage and granularity being equal, make for less work. The textbook example of a branch-heavy function is Plone's buildFolderTree(). My CustomNav product, which wraps it, needs a whole boatload of tests just to cover all the inherited special cases. I would have gone insane developing it without that automation. Happy hacking! Erik Rose -- View this message in context: http://n2.nabble.com/Committed-to-TDD-in-2010-tp4248340p4251941.html Sent from the Product Developers mailing list archive at Nabble.com. _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
