Testgetriebene Entwicklung mit Access

Die Entwicklung von Access-Datenbanken und Begriffe wie „Testgetriebene Entwicklung“, „Unit-Testing“ oder „Refactoring“ passen nicht unbedingt zusammen – zumindest wenn man der landläufigen Meinung glaubt oder die eine oder andere Google-Suche hinzuzieht. Dabei hat die testgetriebene Entwicklung Vorteile, die nicht nur der objektorientierten Welt vorbehalten sind.

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.