Wir führen derzeit eine OpenCover-Sitzung aus, auf der die Datei "nunit3.console.exe" ausgeführt wird.Verbesserte Geschwindigkeit openCover
Unsere Befehlszeile ist der folgende:
"C:\Program Files (x86)\OpenCover\OpenCover.Console.exe" -output:"%CD%\opencover.xml" -register:user -target:"C:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe" -targetargs:"Solution\our-solution-file.sln --config=Debug --result=%CD%\TestResult.xml;format=nunit2"
exit 0
Wir erwarten dies als unser normaler Unit-Test, langsamer sein aufgrund der Instrumentierung dazwischen, aber nicht so viel.
Ohne Codeabdeckung dauert der Komponententest ungefähr 1h. Und derzeit, mit der Code-Abdeckung, haben wir bereits 3 Tage und 23 Stunden verbracht, und wir denken, dass wir nur weniger 10% ausgeführt haben.
Diese Ergebnisse sollten nach SonarQube exportiert werden.
Gibt es etwas, was wir tun können, um die Geschwindigkeit zu verbessern (außer den Computer zu aktualisieren, der den Test ausführt, was wahrscheinlich sowieso gemacht wird)?
Wie weniger detaillierte Ergebnisse, ...? Uns interessiert vor allem die Code-Coverage, die Dauer und andere Sachen sind für uns nicht sehr interessant. Oder sogar ein anderes Werkzeug als OpenCover verwenden.
Ich weiß nicht, ob das wichtig ist, aber diese Zeile wird von Jenkins ausgeführt.
Eine Verlangsamung von 60x ist geradezu lächerlich. Aber diese SO-Antwort legt nahe, dass es eine Eigenschaft von OpenCover ist: http://StackOverflow.com/a/26225013/120163 Die Bemerkung über die Verwendung von Threads und Warteschlangen ist ziemlich überraschend; Diese Mechanismen sind sehr langsam, wenn sie Teil des Laufzeitkerns des Tools sind. Ich würde erwarten, dass ein gutes Test-Coverage-Tool 15 bis 20% zusätzlichen Overhead zur Ausführung hinzufügt. . Werkzeuge für semantische Designs (meine Firma) haben diese Eigenschaft. (Siehe Bio). –