Overview

Testing is important. All software developers know it, but (hardly) anyone does it. [] Luckily, you have bought this tutorial and therefore don't belong to this ignorant crowd ;-) There are many reasons for the poor interest of programmers in the quality of their own products. Education plays an important role. Academically educated computer scientists hear of the fact that software has to be tested mostly as a theoretical topic within their two-semester software course. The autodidacts among programmers normally find nothing in their textbooks and coding tutorials, except a note that programs should "of course" be thoroughly tested. Only you won't find how and why in these tutorials, with a few praiseworthy exceptions, like those by Hunt and McManus [98] and Larman and Gutherie [00]. Eventually, developers build their own stock of prejudices and reasons reinforcing their dislike for testing. Here a few examples.

"I have no time for testing."

This frequently heard sentence assumes that testing takes a great deal of time. If you believe this, you will be caught in a vicious circle. The greater the time pressure, the fewer tests; the fewer tests, the more unstable your code. The more unstable your code, the more error reports will fly in from customers. The more error reports, the more debugging time will be required. The more debugging time, the greater the time pressure. ... On the other hand, if you believe that tests stabilize your code, then this vicious circle will turn into an open spiral. The more stable your code, the less debugging time will be required. The less debugging time, the more time left for development (and tests). This is what this tutorial is about.

"Software testing is boring and mindless."

Common literature about software testing [, ] is rather dry and theoretical, scaring off more practically oriented programmers. However, a closer look reveals that the discovery and thus avoidance of software errors is a demanding and creative activity, just like coding itself, more so. Early testing can even help to control the coding process and make it more satisfactory because we gain more confidence in the results of our work. This is what this tutorial is about.

"My code is virtually faultless, good enough in any event."

We as developers like to believe in our own intellectual brilliance. After all, we have read all the tutorials about the issue, have fallen in all the traps, and know all published design patterns plus the details of 363 classes of our own frameworks by heart. Still, sudden doubts creep up at the slightest change to class 276, leaving us wondering what impact that new line of code may have on other parts of the system. Wouldn't it be great if we could use a set of proven and automated tests to check whether an improvement at one end won't inadvertently disturb a function at the other end? This is what this tutorial is about.

"The test department does the testing; they do this much better anyway."

After all, there are exactly the type of pedantic and fussy people in our test department needed for a job like running the same test scripts over and over again. What a pity that test theory provides a few massive indications and proofs that the test department cannot, in fact, do our job, which leads us to the statement of the anti-decomposition axiom. [] This axiom states that testing a composite system is not sufficient to discover errors in its components. This means that the programmer is responsible for additional testing of his or her components in an isolated environment. Also, errors found at an earlier stage can be removed much faster and at less cost. And this is what this tutorial is about. []In my experience this is a sad truth in the field of plain business app development but-as one reviewer remarked-not in other areas like telecommunications, where intensive unit testing is an absolute must to provide software with the required reliability. []The three test axioms will be discussed more closely in Chapter 7.