Test Driven Development mit Excel VBA - einige Hinweise dazu

Test Driven Development scheint mit Excel VBA nicht möglich zu sein, weil nicht vorgesehen. Man kann sich aber einen Arbeitsprozess und Code für dessen Umsetzung aufbauen, der sehr nahe an die gewünschte Arbeitsweise rankommt.

Test Driven Development ("TDD") hat viele Vorteile und sollte meines Erachtens bei jedem Projekt zum Einsatz kommen, das nicht bloß einmalig zum Einsatz kommt und dessen Entwicklung länger als eine Stunde dauert.

Excel VBA ist nativ schlecht ausgerüstet, um TDD anzuwenden. Man kann sich aber einer Arbeitsweise annähern, die effizient ist und TDD weitgehend entspricht, indem man die dafür benötigten Werkzeuge einmalig einrichtet und dann jeweils darauf zurückgreift.

In meinem "Flow Framework Self-Contained" für Excel VBA-Lösungen ist eine gute Möglichkeit für weitgehend automatisierte Tests enthalten. Das Framework ist noch nicht öffentlich verfügbar, das wird noch eine Weile dauern. Am Beispiel dieses Frameworks erkläre ich ganz allgemein, wie ich das dort gelöst habe.

Es gibt jeweils eine Klasse für (1) das Testen von einzelnen Prozeduren/Methoden, (2) aller Prozeduren/Methoden eine(s/r) Moduls/Klasse sowie (3) des gesamten Projekts.

Das heißt: Eine Instanz von (1) pro Prozedur/Methode, eine Instanz von (2) pro Modul (lässt alle (1) des Moduls automatisch laufen) und eine Instanz von (3) pro (Teil-)Projekt (lässt alle Instanzen von (2) automatisch laufen).

Mit nur einem Aufruf kann ich also jederzeit alle Tests laufen lassen, bei jeder Änderung des Codes weiß ich sofort, ob danach alles noch funktioniert - falls die Tests hinreichend gut sind!

Die Tests werden in eigenen Modulen geschrieben, die nur Tests und ggf. Hilfsfunktionen dafür enthalten, alle in das TDD involvierten Komponenten können vor Auslieferung problemlos entfernt werden, ohne den Produktionscode anpassen zu müssen.

Zur Sammlung von Tests und Testergebnissen werden Collections verwendet. Während das Testen von Klassen sehr einfach ist, weil man bei Instanzierung nur für Testzwecke meistens die Möglichkeit hat, dabei die Ergebnisse aus dem Test heraus auszulesen, besteht bei Prozeduren die Herausforderung darin, Ergebnisse direkt in einer Prozedur zu sammeln und die Prozedur dennoch ausführbar zu gestalten, wenn kein Test läuft bzw. die Testmodule gar nicht Teil des Projekts sind.

Wenn Tests Sheet-Operationen beinhalten, kann man ein dafür vorgesehenes Worksheet verwenden, welches statt des sonst verwendeten Worksheets verwendet wird, wenn ein Test läuft. Damit vermeidet man unerwünschte Datenveränderungen.

Die erfolgreiche Ausführung einer Methode/Prozedur ist dabei ein gesonderter Testfall, weil ein Scheitern die Ausführung der übrigen Tests für die Methode/Prozedur im Regelfall verhindert, je nach Error Handling.

Auf diese Weise gelingt mir ein Arbeitsprozess, den man bei der Entwicklung mit Excel VBA so normalerweise nicht kennt: Für jeden zu codenden Baustein kann ich zuerst einen scheiternden Test schreiben, was in der Regel sehr rasch geht. Dann schreibe ich den Code, um den Test zu bestehen und führe ggf. auch alle anderen Tests aus, falls es Wechselwirkungen mit anderem Code gibt. Mitunter erreiche ich dabei eine Zyklusgeschwindigkeit, wie man sie von Sprachen gewohnt ist, die TDD bereits nativ unterstützen.

Falls es Fragen zur konkreten Umsetzung gibt, kontaktiere mich gerne. Ansonsten warte gerne auch auf die Veröffentlichung meines Frameworks - für viele Anwendungsfälle wird die Nutzung kostenlos sein.

Anders Balari, 16.06.2020