2016-03-15 17 views
8

Ich versuche herauszufinden, wie meine Tests eingeschränkt werden können, so dass der Coverage-Reporter nur eine Funktion berücksichtigt, die ein Test abdeckt geschrieben speziell für diese Funktion.Wie man spezifiziert, welche Funktionen/Methoden durch einen Test mit Karma, Jasmine und Istanbul abgedeckt werden sollten

Das folgende Beispiel aus den PHPUnit doc zeigt ziemlich gut, was ich zu erreichen versuchen:

Die @covers Anmerkung kann im Testcode verwendet wird ein Testverfahren zu spezifizieren, welche Methode (n) will testen :

/** 
* @covers BankAccount::getBalance 
*/ 
public function testBalanceIsInitiallyZero() 
{ 
    $this->assertEquals(0, $this->ba->getBalance()); 
} 

Wenn der Test oben ausgeführt werden würde, nur die Funktion getBalance als gedeckt markiert werden und keine andere.

Jetzt einige tatsächliche Codebeispiel aus meinen JavaScript-Tests. Dieser Test zeigt das unerwünschte Verhalten, das ich versuche, sie wieder loszuwerden:

it('Test get date range', function() 
{ 
    expect(dateService.getDateRange('2001-01-01', '2001-01-07')).toEqual(7); 
}); 

Dieser Test die Funktion getDateRange als abgedeckt wird markieren, aber auch jede andere Funktion, die von innengetDateRange genannt wird. Aufgrund dieser Eigenart ist die tatsächliche Codeabdeckung für mein Projekt wahrscheinlich viel niedriger als die berichtete Codeabdeckung.

Wie kann ich dieses Verhalten stoppen? Gibt es eine Möglichkeit, Karma/Jasmine/Istanbul so zu verhalten, wie ich es möchte, oder muss ich zu einem anderen Framework für JavaScript-Tests wechseln?

+0

Was in den Sinn kommt, ist die Verwendung von Dependency Injection und Mocks, um die Anzahl der Aufrufe an tatsächlichen Produktionscode zu reduzieren. – henrikmerlander

+0

stimme ich mit henrikmerlander. Wenn Sie stattdessen echte Funktionsaufrufe anstelle von Mocks innerhalb der getesteten Methode indirekt verwenden, testen Sie diese Funktion ebenfalls – ejosafat

Antwort

2

Ich sehe keinen bestimmten Grund für das, was Sie fragen. Ich würde sagen, wenn Ihr Test verursacht, dass eine verschachtelte Funktion aufgerufen wird, dann wird die Funktion auch abgedeckt. Sie testen dieses Codeteil tatsächlich indirekt. Warum sollte es also nicht in die Codedeckungsmetriken aufgenommen werden? Wenn die innere Funktion einen Fehler enthält, kann Ihr Test diesen Fehler auch dann erfassen, wenn er dies nicht direkt testet.

Sie können den Code mit speziellen Kommentaren mit Anmerkungen versehen Istanbul zu sagen, bestimmte Pfade zu ignorieren: https://github.com/gotwarlost/istanbul/blob/master/ignoring-code-for-coverage.md aber das ist mehr für das Gegenteil glaube ich, nicht Abdeckung zu verringern, wenn Sie wissen, dass Sie nicht einen bestimmten Ausführungspfad sein wollen abgedeckt, vielleicht weil es zu schwer wäre, einen Testfall dafür zu schreiben.

Wenn Sie Ihre "low level" -Funktionen separat testen, sollten Sie sicherstellen, dass Ihr Code modular aufgebaut ist, so dass Sie diese zuerst selbst testen können. Sie können auch verschiedene Testlaufkonfigurationen einrichten, sodass Sie über eine Suite verfügen, die nur die grundlegende Logik testet und die Abdeckung dafür meldet. Wie in den Kommentaren vorgeschlagen, können Spott- und Abhängigkeitsinjektionen helfen, Ihre Tests fokussierter zu machen, aber Sie möchten grundsätzlich immer einige Tests auf hohem Niveau haben, bei denen Sie die Integrationen dieser Teile zusammen überprüfen.

Wenn Sie sich über alles lustig machen, testen Sie nie die tatsächlichen Teile, die zusammen arbeiten.