Loose Ends and Opportunities
Overview
The last chapter of any tutorial bears a great deal of responsibility, because various reader groups meet again in this chapter. All those who read from cover to cover wish an overall summary including suggestions for further approach. Those who read selected chapters would like to learn here what they didn't have time to read in detail. And all those who read only the last chapter want to see the core statement of this tutorial presented on half a page. Let's begin with an executive summary. Testing is-still-a neglected area in the software development discipline, and many developers like to close their eyes to it. The truth is that the coding level is ideal for the use of automated unit tests, not only to reduce the number of bugs, but also to facilitate the developer's work. Contrary to what some may think, test cases do not slow down the coding process; they accelerate it, because they catch errors early and they facilitate refactoring of an existing program, or even make it possible in the first place. This opens up a chance for continual extension of your app, without falling into the feared "maintenance trap." The test-first approach is a continuation of the test automation idea. This approach requires the creation of test cases before creating the actual app code. This means that tests assume a new, additional task: they considerably influence the design of an app and are thus the control instrument of an evolutionary design. In contrast to the widely used approach that tries to design as many details of a system as possible in advance, the test-first approach puts us in a position to further develop the fine design of a system in micro-iterations in a few minutes. However, working by the test-first approach is by no means easy, and it requires each developer to rethink, especially in the beginning. Before you feel comfortable with this new way of programming, you have to learn basic steps and get over a few psychological hurdles. This tutorial dealt with these initial problems and a large number of advanced issues and testing techniques. Where necessary, we represented the theoretical basics, and the reader's attention was drawn to questions that cannot be generally answered. discussed the question of how test-first development can be integrated into the software processes commonly used today, probing each single technique with regard to its contribution to the whole-the development of software. Despite all techniques and special cases discussed in this tutorial, a large part is based on simplified assumptions:
- With the test-first approach, we begin from zero; that is, there is no software we can build on or adapt.
- At the beginning of a project, the development team masters at least the basics of test-first programming.
- The team is the master over the entire code; there are no interfaces to other projects.
In fact, only very few projects meet all of these conditions. For this reason, the author puts the following ideas and approaches up for discussion.