HowTo: Asynchrone Methoden mit Unit Tests testen
Im letzten HowTo ging es um den Einstieg in die asynchrone Programmierung. Ein "Problem" dabei war, dass man nie genau weiß wie lange die Operation dauert. Mit einem kleinen Trick lassen sich auch solche Sachen elegant in einem UnitTest (oder Integrationstest) automatisiert testen.
Szenario
Ich nutze die Codebasis aus dem letzten HowTo und möchte einfach prüfen, ob die "GetCustomersAsync" auch das Event aufruft. Natürlich könnte ich auch die Eventargs entsprechend auswerten.
In einem anderen HowTo hatte ich breits geschrieben wie man Events mithilfe von anoymen Methoden testen kann. Damit ist der Unittest in sich "geschlossen".
Das "Problem"
Da man nicht genau weiß wann die Option durchgelaufen ist (da sie ja asynchron ist) müsste man im Test "Thread.Sleep(1000)" (oder sowas ähnliches) schreiben, damit die Operation beendet ist bevor es zum "Assert…" kommt.
Die "Lösung"
Die Lösung meines Problems habe ich auf diesem Blog gefunden. Mein Unittest sieht jetzt so aus:
[TestClass]
public class CustomerRepositoryTests
{
[TestMethod]
public void GetCustomersAsync_Raised_GetCustomersAsyncCompleted_Event()
{
CustomerRepository rep = new CustomerRepository();
AutoResetEvent reset = new AutoResetEvent(false);
bool eventRaised = false;
rep.GetCustomersAsyncCompleted += delegate(object sender, GenericEventArgs<List<Customer>> args)
{
reset.Set();
eventRaised = true;
};
rep.GetCustomersAsync();
reset.WaitOne();
Assert.IsTrue(eventRaised);
}
}
Wichtig ist die "AutoResetEvent" Klasse, welche in Zeile 8 initialisiert wird.
In Zeile 11-15 ist mein Eventhandler (als anoyme Methode).
In Zeile 16 wird die asynchrone Operation ausgelöst und normalerweise würde nun unser Testframework sofort zum Assert gehen – allerdings braucht die asynchrone Operation eine kleine Weile bis sie durchgelaufen ist.
Das AutoResetEvent Objekt hält allerdings den Thread solange an "reset.WaitOne()" bis "reset.Set()" aufgerufen wurde.
Fazit
Ich finde die Lösung recht einfach, auch wenn ich niemanden raten würde jede asynchrone Operation in jedem Testdurchlauf mit zu testen, da es ja doch manchmal etwas länger dauern kann.
Als Integrationstest oder um manche Sachen automatisiert zu testen, ist die Lösung aber ganz ok und kommen ohne viel Magie aus.







tobsen
28. June 2009
Nunja, diese Möglichkeit setzt jedoch voraus, dass CustomerRepository ein entsprechendes GetCustomersAsyncCompleted-Event zur Verfügung stellt. Ist dieses nicht der Fall ist die Methode GetCustomersAsync() untestbar, oder?
Robert Mühsig
28. June 2009
Eventuell könnten hier diverse Mocking Frameworks helfen. Rhino Mocks ist recht mächtig und dort kann man recht viel machen. So kann man beispielsweise prüfen ob eine bestimme Methode aufgerufen wurde. Diese Variante hier ist natürlich die einfachere.
Laut MSDN sollte es allerdings zu jeder Async Methode ein passendes Completed Event geben, bzw. habe ich das so irgendwo mal gelesen gehabt.
Nico
14. September 2009
Hi,
ist dir eine Möglichkeit bekannt, diese Asynchronität zu nutzen, so wie es in diesem Silverlight-Test-Framework möglich ist (http://jonas.follesoe.no/UnitTestingAsynchronousSilverlightCode.aspx)? Denn bekommt man ein Event ausgelöst, wenn ein Test beendet ist, und dann kann man da noch ein wenig Code ausführen. Weil ich hab jetzt das Problem, dass, sobald die Methode die mit dem “TestMethod”-Attribut gekennzeichnet ist, vorbei ist, ist auch der gesamte Test sofort beendet.. (Hoffe der Satz war nich zu lang.. hehe)
Jan
13. December 2010
Hi, ich bin auch gerade dabei unit tests für meine asynchronen methoden zu schreiben.
Habe ebenfalls AutoResetEvent verwendet, jedoch knallt mir der UnitTest immer mit folgender Meldung weg:
“Der Agent-Prozess wurde angehalten, solange der Test ausgeführt wird.”
Weist du woran das liegen könnte? Ich benutze das Test-Zeugs ausn Visual Studio 2010.
Wäre super wenn du miir per email antworten könntest.