Only in very few cases can software be verified completely based on specifications. Because of this, testing is extremely important in software development.
Up to this point we have not explicitly addressed the role of testing in the software development process. This is not because we believe that testing is unimportant or secondary, but because it essentially plays the same role in MDSD as in other methods. Agile processes [Coc01] [Bec02] can serve as role models in this case: testing constitutes a sort of safety net for the modifiability and extensibility of software. This is why tests should not be run at the end of a project, but frequently during the project.
Test automation [HT04] [Cla04] is a key element for enabling continuous and reproducible validation of the software during its construction. We don’t want to begin with Adam and Eve in regard to testing, but rather to concentrate on specifics in the context of MDSD in general and architecture-centric MDSD in particular.
We mentioned in the previous chapter that we divide a project into an architecture development thread and an application development thread. Both threads are synchronized via milestones; yet they produce different artifacts: The application development thread yields an application, the architecture development thread a domain architecture. We begin with the aforementioned, but before we get started, we wish to give a brief general introduction to the different types of tests.