[Product-Developers] Committed to TDD in 2010

[Erik Rose]

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.