Infotropism Kirrily Robert’s blog

Posted
27 November 2007 @ 3pm

Categories
Tech

Test Driven Development tutorial

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

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).

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
Tags: , , , , , , , , , , , , ,

3 Comments

Posted by
Skud
29 November 2007 @ 7am

bignose, there’s a download link there for the slides in PDF format. Is that free enough for you?


Posted by
bignose
29 November 2007 @ 11am

> 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?


Posted by
Aristotle Pagaltzis
30 November 2007 @ 10pm

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.


Leave a Comment

Vanuatu and OpenStreetmap In which I join Ravelry