Is Unit Testing Extreme

Is using large amounts of UnitTests (for example, a test-main() in every Java class) really ExtremeProgramming?

An extreme climber isn't a guy that builds a set of scaffolding that goes all the way up the cliff, requiring that all parts of the cliff be reachable from the scaffold. An extreme climber grabs a rope and hits the rocks.

So what's all this about requiring that all the code have working test cases which are to be kept up as the code grows? Not that it's a bad idea; I just don't see how it's 'extreme'. Seems pretty conservative to me.

Of course it protects you; the scaffolding protects the climber too. Seems to me that an 'extreme' climber, or programmer, wouldn't want the scaffold. Of course, this will lead to a lot of extreme programmers getting Darwinized, but isn't that the point? If you can't stand the heat, get out of the gene pool.

This view of 'extreme' leaves me with the picture of the oh-so upper crust gentleman in a suit who raises one arm and quietly says 'yippee', then looks around furtively, clears his throat and straightens his tie. :-) 'Balls to the wall, wot?'

-- KevinKelley

My take on this.. Imagine a circus. There are performers walking the tightrope. They could do it without a net and be lauded for their heroism. People might even pay to see them without the net just on the chance that they may fail. But development isn't entertainment. In development, you have a tightrope walker but the client is on their backs as they walk across the tightrope. Even if the developer doesn't mind crashing, the client would. And the developer should if they are at all responsible or at the very least care about their reputation.

My sense has been that extreme means that you are extremely committed to doing the best that you can. Feeling your efficacy and being proactive. -- MichaelFeathers

I've probably been watching too many MountainDew commercials -- KevinKelley

$0.02: coding without unit-testing isn't extreme, it's suicide. It doesn't matter how good you are at grinding out code if your code is unmaintainable, and maintainability requires good test support. XP's CodeUnitTestFirst allows it to do away with a lot of traditional hokey analysis documents, to ditch CodeOwnership, to peform ContinuousIntegration and to safely plan in NanoIncrements. There's no way XP could do such things without its emphasis on testing.

The climbing equivalent of no UnitTesting is to use no ropes or gear. In fact there are folk who climb like that - this is EvolutionInAction. -- PeterMerel

The word "extreme" doesn't actually mean much; it's just marketing. You can't figure out "ExtremeProgramming" by knowing what "extreme" means; you have to look at the 4 ExtremeValues to see what direction it's taken.

One of the values is aggressiveness, and you can arrive at much of XP by taking a bunch of platitudes that everyone already knows (see ExtremeTautologies) and applying them aggressively and religiously across the board. So maybe it should AggressiveProgramming?. Anyway, one of the platitudes is that testing is a good thing, so unit testing is "extreme" in the sense of being part of the method.

-- DaveHarris

I chose the word, so I get to say what I meant by it. The notion of extreme sports is only superficially about young people doing stupid stuff and dying. The extreme sports figures that last are those that combine courage with technical skill. It may look crazy from the bottom of the mountain, but an extreme skier is probably more safe doing what they do than I am doing whatever it is I do on skis.

My model is Patrick de Gayardon, the inventor of skysurfing. He always prepared meticulously for his dives, even though what he did looked crazy (you may have seen pictures of him making a dive into a sinkhole and popping his chute below ground level). He was killed earlier this year when his chute failed to open.

So, to return to the original question, is unit testing extreme? Yes, because if you do it, you program faster. CodeUnitTestFirst has fabulous long term consequences, but the bottom line is that at the end of a day, you get more done writing the tests first.

-- KentBeck

As I recall, the "X" in XP was about taking good practices to an extreme -- not bad practices. Coding like mad 'til deep in the morning and doing no testing would be extreme: It would be extremely bad. XP takes a good practice, testing, and "takes it to extremes" -- TestEverythingThatCouldPossiblyBreak. XP is about taking recognized good practices to extremes, not taking recognized bad practices to extremes. (in my partly-informed opinion) -- JeffGrigg

Extreme programming is extreme because of the things you don't do. Writing unit tests for every method that could break is not very extreme. Not doing object models, not doing interaction diagrams, not spending 2 months at the beginning of the project deciding what every object is and what it will do, that's extreme. Just writing the program, that's extreme.

RelentlessTesting is what allows you to be extreme. -- ChetHendrickson

The reason for this page's existence, I assume, is because CodeUnitTestFirst is one of the more "heavyweight" aspects of XP. That is, it is a lot of work done up front that is expected to pay off, but may not, or may only pay off in intangible ways. And creating unit tests is work that is not directly related to creating the system the customer wants--it contributes to the process, not the product. That doesn't mean that unit tests are a bad thing, but it would be interesting to know if anyone has found more "lightweight" ways to ensure that the system works as intended. --KrisJohnson

How about CCR (CodeCompileRun?)? If it doesn't then fix it so it does. Since an Extreme Programmer know what to do, and when to do it and has a shadow that also knows the same, this should work. The tests, Yagni! Since no big plan up front was needed to define what to do, and since you can always RefactorMercilessly instead, you just do the simplest thing that can possibly work! Writing a bunch of tests sounds a lot like planning and specifying which are a no-no if you are an extreme purist. An extreme program should work so well it can handle any kind of input and decide if it is correct or properly configured etc. The code should be discriminatory and selective, throwing out garbage and handling data it does want, then providing the necessary output or functionings in response. GarbageInGarbageDiscarded?, DataInDataHandled?. That's extreme programming.

Planning and specifying aren't no-nos for XP; they just don't try to look too far ahead in their crystal balls. Planning what you are going to do for the next few hours and specifying what the outcome of that few hours will be is very extreme. And it is very risky to RefactorMercilessly if you have no way to verify that the still system works the same after the refactoring as it did before.

I can understand the idea that writing the FunctionalTests first, then coding to them, is good. But what's 'extreme' about building monster UnitTest scaffolds?

It's extremely comforting when you see the GreenBar. :o)

See IsXpUnitTestingBest