Das automatisierte Testen der GUI (grafical user interface) einer Desktop Anwendung ist auf den ersten Blick eine größere Herausforderung. Doch mit ein paar simplen Tricks kommt man bereits sehr weit. Ich stelle Ihnen im folgenden einige einfache Möglichkeiten anhand eines Beispiels vor.

Ressourcenzugriffe wie das Lesen oder Schreiben von Dateien oder Datenbankzugriffe bereiten beim automatisierten Testen häufig Probleme. Ganz überwiegend liegt das daran, dass der Zugriff auf eine Ressource, wie eine Datei oder Datenbank, mit anderen Aspekten im Code vermischt ist. Innerhalb einer Methode wird dann sowohl auf die Ressource zugegriffen als auch mit den gelesenen Ergebnissen gearbeitet. Das Vermischen der Aspekte erschwert das automatisierte Testen.

Events spielen eine große Rolle in .NET Anwendungen. Häufig basieren große Teile der Verbindung zwischen der UI und „dem Rest“ der Anwendung auf Events. Auch außerhalb der UI gibt es viele Stellen, an denen Events sehr nützlich sind. Hier wäre vor allem das Thema asynchrone Aufrufe zu nennen. Asynchrone Aufrufe bestehen oft aus einer Methode, über die der asynchrone Vorgang gestartet wird, sowie einem Event, über den das Resultat geliefert wird, sobald es zur Verfügung steht.

Doch wie testet man Events automatisiert? Der Beitrag gibt Antworten.

Im Kontext von automatisierten Tests fallen Exceptions in eine der beiden folgenden Kategorien:
(a) Eine Methode löst selbst eine Exception aus, wenn sie einen Ausnahmezustand entdeckt.
(b) Während der Ausführung einer Methode kann eine Exception auftreten, auf die die Methode reagiert.
Der Beitrag beschreibt, wie solche Fälle automatisiert getestet werden können.

Sind Sie schon über das Attribut InternalsVisibleTo gestolpert? Es ermöglicht Ihnen das Testen von internal Methoden. Warum ich das für sinnvoll halte, erläutert der folgende Beitrag. Unter anderem erfahren Sie etwas über Blackbox und Whitebox Tests sowie über den Unterschied von Integration und Operation.