Test Driven Development tutorial
2007 November 27
I’m at OSDC in Brisbane this week. Yesterday I presented my half-day tutorial on Test Driven Development, and promised I would put the slides online. Here they are.
I’ve also uploaded my slides from Packaging Perl Modules: From CPAN to Your Project. If anyone else has slides from OSDC, I highly recommend slideshare.net for making the available. Tag them with “osdc2007″ and they’ll be easily findable by other attendees (and those who just wish they were here).
3 Responses
Comments are closed.
bignose, there’s a download link there for the slides in PDF format. Is that free enough for you?
> there’s a download link there for the slides in PDF format
Which “there”? I see an embedded Flash object, and links to various pages at slideshare.net with zillions of links, none of which have the text “PDF” anywhere on the page.
If there’s a simple link to the PDF document, could you please put that in your post so we don’t have to navigate the entire slideshare.net site for it?
Re: black box vs glass box:
It’s a mistake to make this into an either-or issue. It touches upon the distinctions between unit, functional and acceptance tests. You want to do both – consciously separate, if possible, or consciously alone, if you can’t segregate your tests without incurring a large burden. Just as having glass box tests allows you to freely refactor and debug the implementation of individual concerns, not having them allows you to freely refactor and debug the lines along which the concerns are separated. Tests are as much a hindrance as they are an aid if they make too many assumptions about the code guts based on a very specific implementation as it existed at a very specific point in time.
The logical conclusion is that you try to have it both ways by doing glass box testing separately from black box testing, so that you have one set of tests that specifies the assumptions that are public and invariant over code refactors, and one set of tests for the guts that is understood to be volatile and having to track changes to the code. But if you don’t have the discipline to do that, or the project scope (and therefore test suite scope) is too small to warrant such a structured testing approach, then glass box testing is indeed preferable over black box testing.