none
Testen von Komponenten die asynchron arbeiten RRS feed

  • Frage

  • Hi,

    wir haben Komponenten die asynchrone Logik kapselt. Nun meine Frage, wie kann ich diese testen, da ja meine Assert's mal richtig aber ehr zu früh ausgeführt werden ?

    Gib es so was wie ein globaler Auf-Alle-Thread's-Warten-Befehl ?

    Wie geht man da am besten vor ?

    Grüsse

    Attila


    • Bearbeitet Attíla Sonntag, 7. April 2013 22:01
    Sonntag, 7. April 2013 12:25

Antworten

  • Hi eolith,

    wenn ich dich richtig verstanden habe, hast du Abhängigkeiten zwischen den Threads.

    Damit bist du nicht mehr direkt bei Unit Test, sonder bei Integrationstests.

    Hier sollte die erste Überlegung sein, den Code der getestet werden soll so zu extraieren, das er unabhängig von den Threads getestet werden kann. Was eigentlich gehen sollte. (Refactoring z.B. extract Method).

    Integrationstest für Mutithreading Anwendungen sind nicht ganz trivial zu schreiben.

    Und selbst wenn deine Tests funktionieren ist nicht sicher gestellt, dass es nicht doch Probleme beim eigentlichen Betrieb gibt. (z.B. weil die Festplatte schneller oder langsamer ist). Hier kommt es einfach darauf an, was man implementiert hat.

    Je nachdem was du macht kann es auch sinnvoll sein LoadTest zu schreiben.

    Was das synchronisieren von Threads angeht solltest du mal hier schauen.

    Wo man auch vielleicht noch mal rein schauen kann ist das kostenlose E-Book zu Microsoft Fakes.

    MFG

    Björn

     

    • Als Antwort markiert Attíla Sonntag, 7. April 2013 22:08
    Sonntag, 7. April 2013 14:29

Alle Antworten

  • Hallo, wenn ich einen BP setze, dann werden alle Threads angehalten, ansonsten wird von VS versucht alles wie bei einem normalen ausführen alles "zeitgleich" auszuführen.

    Ansonsten schau dir mal folgendes an:
    http://stackoverflow.com/questions/4144534/pausing-all-threads-in-current-process-at-run-time


    <Code:13/> - Koopakiller [kuːpakɪllɐ]
    Webseite | Code Beispiele | Facebook | Snippets
    Wenn die Frage beantwortet ist, dann markiert die hilfreichsten Beiträge als Antwort und bewertet die Beiträge. Danke.
    Einen Konverter zwischen C# und VB.NET Code gibt es hier.

    Sonntag, 7. April 2013 12:44
    Moderator
  • Hi,

    einstweilen Danke aber evtl. hätte ich noch folgendes erwähne sollen:

    1. Mit "Testen" meine ich die UTest, sprich die automatischen Komponententests, daher keine BP's

    2. Es wird später WinRT betrf. daher auch keine API Aufrufe

    Sonntag, 7. April 2013 13:04
  • Hi eolith,

    wenn ich dich richtig verstanden habe, hast du Abhängigkeiten zwischen den Threads.

    Damit bist du nicht mehr direkt bei Unit Test, sonder bei Integrationstests.

    Hier sollte die erste Überlegung sein, den Code der getestet werden soll so zu extraieren, das er unabhängig von den Threads getestet werden kann. Was eigentlich gehen sollte. (Refactoring z.B. extract Method).

    Integrationstest für Mutithreading Anwendungen sind nicht ganz trivial zu schreiben.

    Und selbst wenn deine Tests funktionieren ist nicht sicher gestellt, dass es nicht doch Probleme beim eigentlichen Betrieb gibt. (z.B. weil die Festplatte schneller oder langsamer ist). Hier kommt es einfach darauf an, was man implementiert hat.

    Je nachdem was du macht kann es auch sinnvoll sein LoadTest zu schreiben.

    Was das synchronisieren von Threads angeht solltest du mal hier schauen.

    Wo man auch vielleicht noch mal rein schauen kann ist das kostenlose E-Book zu Microsoft Fakes.

    MFG

    Björn

     

    • Als Antwort markiert Attíla Sonntag, 7. April 2013 22:08
    Sonntag, 7. April 2013 14:29
  • Hi Björn, danke für Deine Antwort und Menge zum lesen gewesen. Ich werde das Projekt mit ...ResetEvent spicken und wie Du schon gesagt hast die teile der Klassen refaktorieren. bb Attila
    Sonntag, 7. April 2013 22:14