Wie Unit-Test eine Methode, die Threads erzeugt?

Question

Ich bin ziemlich neu zu TDD, aber habe es lange genug verwendet, um zu verstehen, wie man Mocks, Stubs, Abhängigkeitsinjektion, Inversion der Kontrolle verwendet, um "ähnliche" Probleme zu lösen ... aber aus irgendeinem Grund fühle ich mich sehr unwohl über die Verwendung Abhängigkeitsinjektion und Weitergabe in einem 'IThread' (oder ähnlich).

Um einen grundlegenden Kontext zu geben - ich versuche Unit-Tests zu einer Legacy-Anwendung hinzuzufügen und ich bin unsicher, wie Unit-Test eine Klasse, die Konstruktor spawns zwei Threads ist.

Ist die einzige Option, die Abhängigkeitsinjektion zu verwenden?

Wenn ja, was ist mit der Funktionalität, die die Threads bringen? Wie es aussieht, laufen die Threads beide während (wahre) Schleifen und verlassen die Schleife nie (es sei denn, die Anwendung beendet). Innerhalb der Loops gibt es vernünftige Code-Stücke und es ist dieser Code, den ich wirklich testen möchte.

Um die Sache noch schlimmer zu machen möchte ich nicht alle Funktionalität aus den Schleifen und in öffentlichen Methoden (ich testen nur öffentliche Methoden, wie meine Tests in einem anderen Projekt existieren), wie es wirklich verringern wird Einfache Verwendung der Klasse an anderer Stelle im Code.

Irgendwelche Vorschläge?

Answer 1

Könnten Sie die Funktionalität in interne Methoden ziehen und stattdessen InternalsVisibleTo verwenden? Selbst wenn Sie wirklich wollen, dass sie privat sind, ist dies eine vernünftige Kompromisslösung.

Wenn Ihre Fäden normalerweise immer laufen würde, dass es sehr schwer zu testen macht ... und es klingt wie Sie wirklich testen sollten, „was die Fäden tun“ Teil getrennt, wenn sie es nicht tun abhängen in separaten Threads zu sein.

Eine Option, die gelegentlich nützlich ist, ist eine IScheduler Art von Schnittstelle zu haben - fragen Sie, um eine Aktion auszuführen, wo immer es passt; Bei der Produktion würde man einen neuen Thread erstellen, aber bei dem Test könnte man die Aktion innerhalb des vorhandenen Threads (oder auf einem Thread, den Sie innerhalb Ihres Testcodes kontrollieren) ausführen. Ich bin mir nicht sicher, ob das für Ihre Situation hier angemessen ist, wo der Thread für immer laufen würde, aber Sie könnten darüber in anderen Situationen nachdenken.