Ja, ich weiß: ordentliche Model-Klassen öffnen nicht zur Laufzeit modale Dialoge. Aber das Leben ist nunmal kein Ponyhof bzw. der Job ist nicht die Uni und so kommt es durchaus vor, dass es schon tausende Zeilen Code gibt, bevor die erste Testmethode dazu geschrieben wird. Gefällt mir auch nicht, ist aber eben so. Seit heute früh verzweifele ich an einer Unit-Testklasse, die das Visual Studio Unit-Test-Framework hängen bleiben ließ, und da ich jetzt endlich eine Lösung gefunden haben, klebe ich sie mir mal ins Blog, um sie das nächste mal schneller finden zu können.

Im aktuellen Projekt gibt es eine "Utility"-Klasse, die ich der Einfachheit halber mal UTILITY nennen werde. UTILITY ist eine herzerfrischend komplexe Angelegenheit, die mit uralten COM-Klassen herumjongliert und weil diese COM-Rotze extrem beschissen zu bedienen und völlig grottig dokumentiert ist, habe ich mir eben UTILITY geschrieben, um mir meine geistige Gesundheit zu bewahren. Nun gibt es im laufenden Betrieb ungefähr 1.000 Dinge, die schief gehen können, weil entweder der Anwender Bullshit macht oder weil die COM-Klassen wirre Exceptions durch die Gegend werfen, weil die dahinter liegende Applikation wirrer ist als ein Spaghettiberg von der Größe des Matterhorns.

Um es kurz zu machen: UTILITY zeigt dem Anwender an vielen Stellen eine Fehlermeldung. Und damit die Sache nicht zu einfach wird, verwenden wir dazu keine normale MessageBox, sondern eine MessageBoxNice, die optisch an den Rest der Applikation angepasst ist, sich intern einen Dialog zusammenpopelt der dann per modal anzeigt wird, d.h. der Rest des Programms wartet auf einen Klick des Anwenders, bevor es mit der Ausführung weiter gehen kann.

Und das gefällt dem VS-Testframework mal sowas von gar nicht. Diese simple Testmethode:

1 <TestMethod()>
2 Public Sub TestMethod1()
3 Dim cK As CooleKlasse = UTILITY.MachWat(workDocument, "WTF", "whatever")
4 Assert.IsNotNull(annotSet)
5 Assert.AreEqual("WTF", cK.Name)
6 End Sub

lief bis Zeile 3 und dann passierte einfach nichts mehr. Nichts. Ein Debugging in der Methode .MachWat förderte zutage, dass darin eine Exception abgefangen wird und anschließend eben jene oben beschriebene hübsche MessageboxNice aufpoppen sollte. Tat sie aber nicht. Und nochmal: ja, ich weiß, dass das alles Mist ist. Zu testende Methoden haben keine Dialoge anzuzeigen. Schiß dr' Hund dropp!

Ich sitze hier seit 2 Stunden und googele mir einen Wolf, wie ich den Mist entweder umgangen oder die Messagebox eben doch angezeigt bekomme. Jetzt endlich habe ich diesen StackOverflow-Thread gefunden, und ich könnte suketh137 gerade knutschen:

I finally had some consistent success (and lack thereof) based on a single form property: ShowInTaskbar.

When a form had that property set to true, such forms would NOT display from a unit test method. When that property is false, all forms display. So, here are the rules as far as I know them to make sure a form can display from a unit test:

The form should be created as a standard Windows Form item in the project.

The form should have its ShowInTaskbar property set to FALSE.

The form needs to be displayed modally (i.e. with ShowDialog()).

This has let me display and test all of my utility forms like date selectors and login screens.

WTF?! Nur wenn die Form das Property ShowInTaskbar auf false gesetzt hat, wird sie während der unitTests angezeigt? Ansonsten hängt sich das gesamte Unittestframework einfach auf?!

Mmmkay.

Danke Internet. Ich kleb' mir das jetzt ins Blog, damit ich es das nächste Mal schneller wieder finde.

PS: und wenn mir das nächste Mal langweilig ist, werde ich mich mal über das MS Fakes Framework informieren

| Abgelegt unter Coding
The views expressed by the author are personal.