This is, in a sense, funny. "Test first" is extremely similar to a subset of Design By Contract. When you design your test cases, you're basically coding the expected post-conditions for method calls. Funny thing is, I've been a strong supporter of Design by Contract and, more generally, of the liberal use of assertions inside code. In most cases, however, I've found two kind of assertions to be the most efficient (meaning: you get real value from the effort you put in). One of them is the precondition. I want to trap programming errors in the calling site easily, and that's what preconditions do. Another kind is the generic assertion, used between portions of complex algorithms, to make sure that my understanding of program state was right. Long distant comes the postcondition, for a very simple reason: it's the hardest to write, sometimes so hard that is makes no economic sense to write one.
I'll skip a few words on how Design by Contract zealots tended to say mostly the same things as the Agile zealot do (only worse: never code a class if you don't have an invariant ready, never code a method without pre/post conditions, and so on). Zealots have this common tendency of confusing means with ends, ultimately jeopardizing the concepts they try so heavily to promote. [I'll even skip some linking back from Design by Contract to formal methods, weakest preconditions and the like (it would be fun, anyway, to trace some XP concepts back to formal methods :-))].
Enough talking, let's get some code running. Your mission, should you choose to accept it, is to code your way through this little problem in a test-first way. You'll have a class, say Canvas, that can display bitmaps, and where you can also get and set the color of each pixel. Your program must load a user-specified bitmap into the canvas, then draw a circle with user-specified center, radius, and color. The circle must be drawn over the bitmap, with smoothing. You have to implement the algorithm for that (you may borrow from the literature, using e.g. the Bresenham algorithm, but you're on your own about the smoothing).
Please, test this first. No code before you have some meaningful test in place. Meanwhile, someone else will use a code-first :-) approach. Let's see what happens ;-).
Winning later because of test automation? Maybe. Now your algorithm should also take a user-specified pen thickness as a parameter. Are your tests ready for that? Easily changed? C'mon.
Of course, test-first is useful in some cases, and has a very desirable side-effect: classes tend to be designed with the caller in mind, which is a good design concept. (Wouldn't be good anyway to know about design concepts and not just about programming techniques? :-))).
It's just that, like any other technique, we should use it only when it makes [economic] sense. Now, that would be agile :-).