Blog posts tagged "tdd"

Simple Test

July 4th, 2006

Recently started using Simple Test for a couple of projects (even slipped it in at work, but sssh! don’t tell them!). So far I’m very happy with it. Using PHPUnit was always a bit of a non-starter, it felt heavy, and even which version (fork?) to use was ambiguous.

Simple Test’s documentation beyond the basics start to trail off, but the code is eminently readable (better then docs any day!), and I found writing a harness to work with the feedparser tests pleasantly straightforward.


Tagged: Uncategorized , , ,

Pirate Testing (Because Only Ninjas Write Unit Tests)

January 30th, 2006

I’ve got a new favorite development technique, “pirate testing”. I’ve used it on 3 recent projects, and it rocks.

And while Sam might have meant it literally, I’ve found it perfectly describes the practice of shanghaiing another tool’s test suite to given your own TDD a jump start.

(n.b.: May be harder in languages which don’t allow reopening of classes. aka monkey patching)

Tagged: Uncategorized , , , , , ,

Atom and Wiki Driven Testing

December 20th, 2005

Its been a long standing todo to port Mark’s FeedParser tests to work against Magpie, possibly with an intermediate representation to allow cross-language testing. (has any work been down on capturing unit tests/acceptance tests in XML?) Sam’s approach hilights Ruby-the-language’s awesome flexibility (I’d been playing with something similar for the parser we wrote for Odeo), but doesn’t map to PHP/Magpie very well.

Phil kicked off a new round of testing for Atom 1.0, the results of which are now captured in the Atom wiki. (not to mention a few gentle nudges on Magpie’s lack of 1.0 compliance.)

All of which got me thinking, it would be exceptionally cool if someone made the FeedParser’s tests available on the Atom wiki using Ward’s FIT concept in a documented, reportable fashion.

Any takers?

Tagged: Uncategorized , , , , , ,

TDD and Blame Management

May 18th, 2005

One of the undiscussed (or at least I haven’t seen it discussed) benefits of test driven development is “blame management.”

“My changes didn’t cause any tests to fail” somehow slips past the filters that would reject, “Not my fault, not fixing it” as unprofessional, and so a certain Darwinian pressure is exerted to provide the best test suite for your most fragile code in the hopes of fending off sweeping, and devastating changes from other developers.

Tagged: Uncategorized , , ,