Wir haben versucht, ein paar Code-Coverage-Plugins für unser Spring-Projekt (EclEmma, Clover) zu verwenden.JUnit und Spring - Code Coverage% ist falsch, wenn mehrere Threads im Test verwendet werden
Beide liefern falsche Ergebnisse in Bezug auf die Abdeckung%.
Die Tests verwenden den taskExecutor von Spring (Thread-Pool).
Der gesamte Code, den der Task-Executor-Thread ausführt, gilt nicht als abgedeckt.
Irgendwelche Ideen warum?
Ich habe gerade das gleiche Problem, aber darüber nachdenken, wie kann JUnit/EclEmma wissen oder verfolgen Code, der auf mehreren/anderen Threads parallel ausgeführt wird? Meine Annahme ist, dass es nur auf dem Haupt/aktuellen Thread funktioniert. Der richtige Ansatz für Komponententests und damit für die Abdeckung besteht darin, den Code, der auf diesen anderen Threads ausgeführt wird, in einem separaten Test zu isolieren und zu testen. Eine Möglichkeit, sich selbst zu überzeugen ... versuchen Sie Breakpointing, während JUnit im Debug-Modus läuft. Das funktioniert auch nicht ... Wenn Sie an einem Haltepunkt hin und her gehen, werden Sie vielleicht feststellen, dass Sie nicht bei der nächsten Anweisung gelandet sind und/oder der Code in einem anderen Thread längst beendet ist und der Test tatsächlich bereits abgeschlossen ist.
"Meine Annahme ist, dass es nur für den Haupt/aktuellen Thread funktioniert." Das ist eine falsche Annahme: [JaCoCo] (http://www.eclemma.org/jacoco/index.html) (von EclEmma genutzte Coverage-Engine) unterscheidet nicht zwischen Threads und kann Coverages erfassen, die von mehreren Threads beigetragen werden. "Wie?" - ist ein bisschen abseits vom Thema. Ich bin nicht vertraut mit Spring taskExecutor, wird nur einige mögliche allgemeine Gründe auflisten: keine Debug-Informationen in der Klasse Dateien, Änderung der Klassen zur Laufzeit, ... (http://www.eclemma.org/jacoco/trunk/doc/ faq.html) Tieferes Verständnis des Problems erfordert ein Beispiel (Reproduzierer). – Godin
Könnten Sie bitte ein Beispiel für einen solchen Code angeben und dafür testen? – Godin