Testgetriebene Entwicklung mit Access
Der übliche Verlauf bei der Entwicklung einer nwendung ist wohl so, dass man einen Teil der nwendung entwickelt – etwa eine Routine, ein ormular oder einen Bericht – und sich dann, enn dieser Teil wie erwartet funktioniert, dem ächsten Teil zuwendet.
Das klappt mehr oder weniger gut, denn bei eitem nicht alle auf den Weg gebrachten Entwicklungen rfahren die Weihen des Praxiseinsatzes. nd diejenigen, die so weit kommen, ringen die Entwickler beim ersten Ruf nach Erweiterungen ur Verzweiflung, weil jede Änderung ich auf unvorhergesehene Weise auf andere nwendungsbereiche auswirkt.
Wie soll die testgetriebene Entwicklung die Anwendung nun vor einem solchen Schicksal schützen?
Kurz gesagt: Indem man dabei für jedes noch o kleine Feature einen automatisierten Test chreibt, der jederzeit per Knopfdruck wiederholt erden und zeigen kann, dass alles wie gewünscht unktioniert. Wichtig ist dabei tatsächlich, ass man sich auf „kleine Einheiten“ – eshalb der Begriff „Unit Testing“ – konzentriert, enn je genauer man die Stelle definiert, an der in Test scheitern könnte, um so einfacher ist das eheben der zugrunde liegenden Funktionalität.