Messung der Codeabdeckung in Delphi

Question

Gibt es eine Möglichkeit, die Codeabdeckung mit Dunit zu messen? Oder gibt es kostenlose Tools, die dies erreichen? Was benutzt du dafür? Für welche Codeabdeckung entscheiden Sie sich normalerweise?

Jim McKeeth: Danke für die detaillierte Antwort. Ich spreche von Unit -Tests im Sinne eines TDD -Ansatzes, nicht nur über Unit -Tests nach einem Fehler. Ich interessiere mich für die Code -Abdeckung, die ich mit einigen grundlegenden vorgeschriebenen Unit -Tests erreichen kann.

Answer 1

Ich habe gerade ein neues Open -Source -Projekt auf Google Code mit einem grundlegenden Code -Coverage -Tool für Delphi 2010 erstellt. https://sourceforge.net/projects/delphicodecoverage/

Im Moment kann es die Leitungsabdeckung messen, aber ich plane, auch Klassen- und Methodenabdeckung hinzuzufügen.

Es generiert HTML -Berichte mit einer Zusammenfassung sowie mit der gekennzeichneten Quelle, die Ihnen zeigt, welche Linien abgedeckt werden (grün), die nicht (rot) und die restlichen Zeilen, in denen kein Code für sie generiert wurde.

Aktualisieren:Ab Version 0.3 von Deckung von Delphi -Code Sie können XML -Berichte erstellen, die mit dem Hudson EMMA -Plugin kompatibel sind Hudson.

Aktualisieren:Version 0.5 bringt Fehlerbehebungen, erhöhte Konfigurierbarkeit und bereinigte Berichte mit

Aktualisieren:Version 1.0 unterstützt die Emma -Ausgabe, die Abdeckung von Klassen und Methoden und die Berichterstattung von DLLs und BPLs

Answer 2

I don't know of any free tools. AQTime is almost the defacto standard for profiling Delphi. I haven't used it, but a quick search found Discover for Delphi, which is now open source, but just does code coverage.

Either of these tools should give you an idea of how much code coverage your unit tests are getting.

Answer 3

Are you referring to code coverage from unit tests or stale code? Generally I think only testable code that has a failure should be covered with a unit test (yes I realize that may be starting a holy war, but that is where I stand). So that would be a pretty low percentage.

Now stale code on the other hand is a different story. Stale code is code that doesn't get used. You most likely don't need a tool to tell you this for a lot of your code, just look for the little Blue Dots after you compile in Delphi. Anything without a blue dot is stale. Generally if code is not being used then it should be removed. So that would be 100% code coverage.

There are other scenarios for stale code, like if you have special code to handle if the date ever lands on the 31st of February. The compiler doesn't know it can't happen, so it compiles it in and gives it a blue dot. Now you can write a unit test for that, and test it and it might work, but then you just wasted your time a second time (first for writing the code, second for testing it).

There are tools to track what code paths get used when the program runs, but that is only simi-reliable since not all code paths will get used every time. Like that special code you have to handle leap year, it will only run every four years. So if you take it out then your program will be broken every four years.

I guess I didn't really answer your question about DUnit and Code Coverage, but I think I may have left you with more questions then you started with. What kind of code coverage are you looking for?

UPDATE: If you are taking a TDD approach then no code is written until you write a test for it, so by nature you have 100 test coverage. Of course just because each method is exercised by a test does not mean that its entire range of behaviors is exercised. SmartInspect provides a really easy method to measure which methods are called along with timing, etc. It is a little less then AQTime, but not free. With some more work on your part you can add instrumentation to measure every code path (branches of "if" statements, etc.) Of course you can also just add your own logging to your methods to achieve a coverage report, and that is free (well, expect for your time, which is probably worth more then the tools). If you use JEDI Debug then you can get a call stack too.

TDD really cannot easily be applied retroactively to existing code without a lot of refactoring. Although the newer Delphi IDEs have the ability to generate unit test stubs for each public method, which then gives you 100% coverage of your public methods. What you put in those stubs determines how effective that coverage is.

Answer 4

I use Discover for Delphi and it does the work, for unit testing with DUnit and Functional testing with TestComplete.

Discover can be configured to run from the command line for automation. As in:

Discover.exe Project.dpr -s -c -m

Answer 5

Discover works great for me. It hardly slows down your application, unlike AQTime. This may not be a problem for you anyway, of course. I think the recent versions of AQTime perform better in this respect.

Answer 6

I've been using Discover" for years, worked excellently up to and including BDS2006 (which was the last pre-XE* version of Delphi i used and still use), but its current opensourced state, it's unclear how to make it work with XE* versions of Delphi. A shame really, because I loved this tool, fast and convenient in almost every way. So now I'm moving to delphi-code-coverage...