Thread by @RonJeffries

while i wait for a call from "the nurse", here are some thoughts about tests, including but not limited to TDD.

XP describes to kinds of tests, Programmer Tests, and Customer Tests. These names describe who the tests primarily serve.

Now in XP there are really only two main roles, programmer and customer. i don't want to argue about this right now, but customer is who the product is being written for, or their representative, and programmers are all the devs, testers, whatever software makers you have.

XP doesn't really contemplate separate testing. Like Scrum, at the end of the iteration, the "programmers" deliver a working tested integrated version of the product. N.B. tested.

Now programmer tests are mostly about the many gears and wheels that make up the product, and those tests give the programmers great confidence that all that stuff works as they intended.

The widgets display, the objects all hook together right, the functions all function as intended. This a much more detailed view than the one that asks whether the program does what's wanted.

Think driver and mechanic. The driver says the car doesn't go, or makes a weird noise, while the mechanic determines the spark plugs are dirty and the tires have no air in them. More detailed, same car.

Customer tests are about whether the product does what it's supposed to do: does it drive & not make any funny noises. The wise mechanic test drives the car before working & before giving it back, and the wise customer test drives before paying. she might take the mechanic along.

Customer tests are best negotiated with the customer: when this story is done, the program will produce this result, looking like this. This avoids a lot of "that's not what I want / it's what you said". Sometimes, with a close enough relationship we can do fewer Customer tests.

Programmer tests are there to give us confidence that all the things are as they should be. The spark plugs spark, the tires have air. We really don't want someone coming back with that kind of problem: it makes us look bad and feel bad.

(These tests can and do blur together. That's fine, we're describing a kind of focus, not a hard line.)

Now we're trying to deliver as much value per time as we safely can. Anything else would be dishonest.

Many of us have found that TDD helps us deliver code with speed and confidence, so we use it a lot, when and where we can. That's not always but it is often.

But my bottom line today is this:

Programmer tests are the best way that I know to deliver working code at an optimal pace. When I test inadequately, someone down the line finds my defect.

That's not OK with me. I'm here to deliver code that works.

Think about that, then do what seems right.