La llamada “sociedad del riesgo”

I haven't used the "A" word anywhere above. Architecture is just as important in XP projects as it is in any software project. Part of the architecture is captured by the system metaphor. If you have a

good metaphor in place, everyone on the team can tell about how the system as a whole works. The next step is to see how the story turns into objects. The rules of the Planning Game state that the result of the first iteration must be a functioning skeleton of the system as a whole. But you still have to do the simplest thing that could possibly work. How can you reconcile these two?

For the first iteration, pick a set of simple, basic stories that you expect will force you to create the whole architecture. Then narrow your horizon and implement the stories in the simplest way that can possibly work. At the end of this exercise you will have your architecture. It may not be the architecture you expected, but then you will have learned something.

What if you can't find a set of stories that forces you to create the architecture you know, you absolutely know, you are going to need? Either you can put the whole architecture in place on speculation, or you can put as much architecture in place now as you need to meet your current needs, and trust that you can put more in later. I put in the architecture I need now and trust my ability to change it later.

Chapter 18. Testing Strategy

We will write tests before we code, minute by minute. We will preserve these tests forever, and run them all together frequently. We will also derive tests from the customer's perspective.

Oh yuck. Nobody wants to talk about testing. Testing is the ugly stepchild of software

development. The problem is, everybody knows that testing is important. Everybody knows they don't do enough testing. And we feel it—our projects don't go as well as they should and we feel like more testing might help the problem. But then we read a testing book and instantly get bogged down in the many kinds and ways of testing. There's no way we could do all that and still get any development done.

Here's what XP testing is like. Every time a programmer writes some code, they think it is going to work. So every time they think some code is going to work, they take that confidence out of the ether and turn it into an artifact that goes into the program. The confidence is there for their own use. And because it is there in the program, everyone else can use that confidence, too.

The same story works for the customer. Every time they think of something concrete the program should do, they turn it into another piece of confidence that goes into the program. Now their confidence is in there with the programmers' confidence. The program just gets more and more confident.

Now, a testing person would look at XP testing and snicker. This is not the work of someone who loves testing. Quite the contrary. This is the work of someone who loves getting programs working. So you should write the tests that help get programs working and keep programs working. Nothing more.

Remember the principle "Work with human nature, not against it." That is the fundamental mistake in the testing books I've read. They start with the premise that testing is at the center of

development. You must do this test and that test and oh yes this other one, too. If we want programmers and customers to write tests, we had better make the process as painless as possible, realizing that the tests are there as instrumentation, and it is the behavior of the system being instrumented that everyone cares about, not the tests themselves. If it was possible to develop without tests, we would dump all the tests in a minute.

Massimo Arnoldi writes:

Unfortunately at least for me (and not only) testing goes against human nature. If you release the pig in you, you will see that you program without tests. Then after a while, when your rational part wins, you stop and you start writing tests. You

mentioned too, pair programming reduces the probability that both partners are releasing their pigs at the same moment. (Source: e-mail.)

First, each test doesn't interact with the others you write. That way you avoid the problem that one test fails and causes a hundred other failures. Nothing discourages testing more than false

negatives. You get this adrenaline rush when you arrive in the morning and find a pile of defects. When it turns out to be no big deal, it's a big letdown. Are you going to pay careful attention to the tests after this has happened five or ten times? No way.

The tests are also automatic. Tests are most valuable when the stress level rises, when people are working too much, when human judgment starts to fail. So the tests must be

automatic—returning an unqualified thumbs up/thumbs down indication of whether the system is behaving.

It is impossible to test absolutely everything, without the tests being as complicated and error- prone as the code. It is suicide to test nothing (in this sense of isolated, automatic tests). So, of all the things you can imagine testing, what should you test?

You should test things that might break. If code is so simple that it can't possibly break, and you measure that the code in question doesn't actually break in practice, then you shouldn't write a test for it. If I told you to test absolutely everything, pretty soon you would realize that most of the tests you were writing were valueless, and, if you were at all like me, you would stop writing them. "This testing stuff is for the birds."

Testing is a bet. The bet pays off when your expectations are violated. One way a test can pay off is when a test works that you didn't expect to work. Then you better go find out why it works, because the code is smarter than you are. Another way a test can pay off is when a test breaks when you expected it to work. In either case, you learn something. And software development is learning. The more you learn, the better you develop.

So, if you could, you would only write those tests that pay off. Since you can't know which tests would pay off (if you did, then you would already know and you wouldn't be learning anything), you write tests that might pay off. As you test, you reflect on which kinds of tests tend to pay off and which don't, and you write more of the ones that do pay off, and fewer of the ones that don't.