Bei der Verwendung meiner Anwendung bin ich auf eine Racebedingung in einem Code gestoßen, der NSOperationQueue verwendet, um Tasks asynchron nach vom Benutzer ausgelösten Ereignissen auszuführen. Ich weiß, wie man die Race Condition beheben kann, da es ein blöder Designfehler ist, auf den ich nicht näher eingehen möchte, aber ich möchte den Bug mit einem Testfall beweisen (damit er während der Optimierung / Refactoring nicht zurückkommt) auf der ganzen Linie). Das hat mich ratlos gemacht. Wie wird man etwas testen, das Multi-Threading ist, besonders wenn es das Ziel des Tests ist, eine Race Condition zu erzeugen?
Hat jemand Links zu Referenzmaterial, auf das ich mich im Umgang mit Threads und Komponententests beziehen kann? Ich bin besonders an der Generierung von Race Condition interessiert.
Sie müssen sicherstellen, dass die Reihenfolge der Ereignisse, die den Wettlauf verursachen, tatsächlich während des Tests auftritt. Dazu müssen Sie das Thread-Interleaving innerhalb des Testfalls beeinflussen.
Das erreichen Sie mit zusätzlicher (bedingter) Synchronisation oder (einfacheren und weniger zuverlässigen) zusätzlichen Timern. Setzen Sie einige sleep () Aufrufe in die kritischen Abschnitte, um sicherzustellen, dass sie lange genug laufen, damit der andere Thread in den unerwünschten Zustand gelangt. Wenn Sie damit arbeiten, ersetzen Sie die Schlafanrufe durch explizite Synchronisation (d. H. Blockieren Sie einen Thread, bis der andere tatsächlich bestätigt, angekommen zu sein).
Dann mache das alles abhängig von einem globalen Flag, das durch den Testfall gesetzt wird.
Tags und Links objective-c unit-testing multithreading cocoa