TABLE OF CONTENTS Remember our introduction? It explained that the approach discussed in this book is based mainly on the technique of writing a test before the actual program code to test this very code. Are we really serious about this? How should I test something that I don't know yet?
Let us go back to the programming problem of Chapter 1, Section 1.3 once again. We repeat the following requirements specification so you don't have to look back:
We want to program a dictionary to translate a German text into a language of our choice, say English. This dictionary, in the form of a class, Dictionary, is initialized with a word file and allows us to query the translation of a German word. The program should allow several translation alternatives.
Let's assume that we were really serious about the test-first claim. What would that approach look like in this example?
"The development progresses in small steps, where testing and coding alternate. Such a 'micro-iteration' does not take more than 10 minutes." We will use this quotation from Chapter 1, Section 1.4 from now on as our guiding principle.
When we begin to develop software, the requirements specification is our primary source of information. Accordingly, for the classes and objects at the outer border of a system, the majority of test cases will somehow be linked to those requirements. To be more precise, the more testable the requirements are, the easier it is to derive...
