Granularitätsebenen in der Codeabdeckung

Die Granularität der Codeabdeckung ist ein wichtiger Aspekt automatisierter Tools, mit denen Metriken für die Codeabdeckung zum Testen gemessen werden. Nicht alle Tools bieten jedoch den gleichen Einblick in die Codeabdeckung.

Um den unterstützten Granularitätsgrad zu bestimmen, fragen Sie sich: „Was ist die kleinste Codeeinheit, deren Abdeckungsstatus ich eindeutig bestimmen kann?“ Bei vielen verfügbaren Tools ist die Granularität auf einzelne Zeilen beschränkt. Dies kann eine größere Einschränkung sein, als es auf den ersten Blick scheint. Das Hauptproblem ist, dass Java, wie die meisten gängigen Programmiersprachen, eine Freiformsprache ist. Ein Entwickler kann eine vollständige Java-Klasse als eine sehr lange Codezeile schreiben. Wenn ein Coverage-Tool, das eine linienbasierte Coverage-Granularität bietet, meldet, dass diese einzeilige Klasse „abgedeckt“ ist, was genau bedeutet das? Bedeutet dies, dass jeder einzelne Ausdruck in dieser Zeile abgedeckt wurde, oder wird eine 100% ige Abdeckung gemeldet, wenn mindestens ein Ausdruck in der Zeile abgedeckt wurde?

Zugegeben, das Beispiel einer Java-Klasse, die als einzelne Codezeile geschrieben ist, ist etwas erfunden, und ein solcher Programmierstil würde bereits Anlass zur Sorge geben. Die linienbasierte Granularität kann jedoch bei einigen häufig verwendeten Redewendungen an ihre Grenzen stoßen. Betrachten Sie die Methode in Listing 1.

öffentliche Klasse Listing1 {static int minOrMax (boolesches Minimum, int a, int b) {Minimum zurückgeben? Math.min (a, b): Math.max (a, b); }}

Auflistung 1: Eine Klasse, die die Grenzen der linienbasierten Abdeckungsgranularität demonstriert

Ein einzelner Test ist erforderlich, um die Zeile mit der return-Anweisung teilweise abzudecken. Es sind jedoch mindestens zwei Testfälle erforderlich, um beide Alternativen des bedingten Ausdrucks abzudecken. Selbst ohne den bedingten Operator ist es nicht schwierig, Situationen zu erstellen, in denen eine Codezeile nur teilweise abgedeckt ist. Ausnahmen während der Programmausführung können immer Teile einer Zeile ohne Abdeckung lassen. Die linienbasierte Abdeckungsgranularität ist in den meisten Fällen ausreichend - solange das Abdeckungstool keine vollständige Abdeckung für Linien meldet, die in Wirklichkeit nur teilweise abgedeckt sind. Es kann auch schwierig sein zu bestimmen, warum eine bestimmte Linie nicht vollständig abgedeckt ist und welche Tests hinzugefügt werden müssen, um eine vollständige Abdeckung zu erreichen.

Coverage-Tools, die Coverage für einzelne Ausdrücke melden, erleichtern die Identifizierung fehlender Testfälle. Die Visualisierung der granularen Abdeckung auf Ausdrucksbasis ist etwas aufdringlicher. Die zeilenbasierte Abdeckung kann problemlos in einem Seitenlineal des Quellcode-Editors angezeigt werden, während für die ausdrucksbasierte Abdeckung Markierungen (wie Färben oder Unterstreichen) im Quellcode selbst erforderlich sind.

In seltenen Fällen führt ein scheinbar atomarer Ausdruck zu mehreren ausführbaren Anweisungen, von denen einige unter bestimmten Umständen möglicherweise nicht behandelt werden. Im Idealfall reicht die Granularität der Abdeckung bis auf die Ebene der einzelnen Anweisungen. Tatsächlich sammeln viele Coverage-Tools Informationen darüber, ob einzelne Anweisungen ausgeführt werden oder nicht. Die Granularität der gesammelten Daten kann jedoch auf ausdrucksbasierte oder zeilenbasierte Abdeckung reduziert werden, wenn sie dem Benutzer gemeldet werden.

Die Gründe für eine geringe Codeabdeckung

Das Problem der Erhöhung der Testabdeckung kann normalerweise auf drei Szenarien reduziert werden:

• Verfügbare Tests verwenden keine Eingabewerte, die dazu führen, dass Steuerausdrücke für Bedingungen im Code alle Zweige ausüben.
• Steuerausdrücke in einer getesteten Funktion hängen von Werten ab, die von anderen Funktionen zurückgegeben werden, also vom Status des Programms / Codes, wenn der Test ausgeführt wird.
• Verfügbare Tests verwenden nicht die richtige Einrichtung für den zu testenden Code. Wenn Sie also einen Test ausführen, wird eine Ausnahme ausgelöst, und der Ausführungsfluss wird zum Zeitpunkt der Ausnahme unterbrochen.

Abhängig von der Struktur des Codes können Steuerausdrücke trivial sein (z. B. eine if / else-Anweisung pro Funktion) oder nicht (Bedingungen für verschachtelte Schleifen mit Steuerausdrücken, die Rückgaben von Funktionsaufrufen sind, die mit Verzweigungsausdrücken vermischt sind). Basierend auf diesen Szenarien sind jeweils unterschiedliche Techniken zur Steuerung der Bedingungen innerhalb des Testrahmens geeignet.

Abdeckung ist nicht alles

Es ist üblich, fälschlicherweise zu glauben, dass die Abdeckung die einzige metrische Fahrqualität ist. Sobald Teams in der Lage sind, die Abdeckung zu messen, ist es nicht ungewöhnlich, dass Manager die Anzahl erhöhen möchten, denn „eine höhere Abdeckung ist besser, oder? Schließlich wird die Nummer selbst wichtiger als das Testen. Darin liegt das Problem - die Abdeckung muss die tatsächliche, sinnvolle Verwendung des Codes widerspiegeln, andernfalls handelt es sich nur um Rauschen. Sofern ein Industriestandard nicht bestimmte Typen und Stufen vorschreibt, muss ein Produkt die Codeabdeckung erfüllen, während wichtig ein pragmatischer Ansatz ist.

Es ist wichtig zu wissen, dass die Kosten für die Deckung mit zunehmender Deckung steigen. Eine zunehmende Abdeckung bedeutet neue Tests, die in Zukunft beibehalten werden müssen. Die Notwendigkeit neuer Tests muss im Hinblick auf das Gesamtprojekt und die Qualitätsziele begründet werden. Das Erstellen von Tests, um die Deckung allein zu erhöhen, führt zu Kosten und technischen Schulden.