2016-02-24 17 views
5

Ich verwende VS 2015 Enterprise, und ich habe einen generischen Komponententest ausgeführt, um die Codeabdeckung zu analysieren. Ich schaue mir die Liste der abgedeckten Blöcke pro Funktion an, und sie scheinen im Allgemeinen korrekt zu sein. Wenn ich jedoch mit der rechten Maustaste auf eine Methode klicke -> "Gehe zum Quellcode", wird sie bei einigen Funktionen an die richtige Stelle im Quelltext (die entsprechende .cpp-Datei) verschoben, bei anderen versucht sie, die Header-Datei zu öffnen (Die Quellzeilennummer ist korrekt, aber der Code befindet sich in der .cpp-Datei - nicht in der .h-Datei. Dies wirkt sich auf die Hervorhebung des Quellcodes aus - die Funktionen, von denen VS glaubt, dass sie sich in .h befinden, sind in der .cpp nicht hervorgehoben. Ich kann keinen Unterschied in den Funktionen feststellen (gleiche Sichtbarkeit, gleiche Kopf- und Quelldateien), außer vielleicht welchen Thread sie aufgerufen haben. Irgendeine Idee, warum VS denkt, dass etwas Code in .h eher als .cpp ist?Visual Studio 2015 Code Coverage Falsche Datei

+0

[mcve] würde helfen. Verwenden Sie Vorlagenfunktionen? – AndyG

+0

Ich stimme zu. Keine Vorlagenfunktionen. – Jeff

+0

Ist das Projekt x64 oder x86? Ich erinnere mich, dass es Probleme mit x64 gibt. – AndyG

Antwort

0

Offensichtlich, obwohl VS 2015 die C++ 11-Funktion non-static data member initializers unterstützt (es kompiliert korrekt), drosselt das Coverage-Tool auf diese Funktion. Hier ist der MCVE. Ich benutze VS 14.0.24720.00 Update 1. Um zu reproduzieren, kompilieren Sie dieses Programm, dann erhalten Code Coverage, indem Sie es mit einem Generic Test ausführen. Wenn x initialisiert wird, sucht das Coverage-Tool nach dem Code für den Konstruktor in der H-Datei. Wenn Sie = 0 herausnehmen, identifiziert es die Konstruktordefinition wie in der .cpp korrekt. In meinem Produktcode waren nicht der Konstruktor, sondern anscheinend zufällige Funktionen, die das Coverage-Tool dachte, in der .h-Datei definiert. Die Fehlerbehebung bestand in meinem Fall lediglich darin, die Datenelementinitialisierung in die Konstruktorinitialisierungsliste zu verschieben.

.

// .cpp 
#include "Test.h" 

#include <iostream> 

Test::Test() 
{ 
    std::cout << "in Test()" << std::endl; 
} 

Test::~Test() 
{ 
} 

void Test::Func1() 
{ 
    std::cout << "in Func1" << std::endl; 

    Func2(); 

    Func3(); 
} 

void Test::Func2() 
{ 
    std::cout << "in Func2" << std::endl; 
} 

void Test::Func3() 
{ 
    std::cout << "in Func3" << std::endl; 
} 
Verwandte Themen