Utilizzo VS 2015 Enterprise e ho eseguito un test di unità generico per analizzare la copertura del codice. Sto osservando l'elenco dei blocchi coperti per funzione, e in generale sembrano corretti. Tuttavia, quando faccio clic con il pulsante destro del mouse su un metodo -> "Vai al codice sorgente", su alcune funzioni esso va nella posizione corretta nel codice sorgente (il file .cpp rilevante), mentre su altri tenta di aprire il file di intestazione (il numero della riga di origine è corretto, ma il codice è nel file .cpp, non nel file .h). Ciò influenza l'evidenziazione del codice sorgente - le funzioni che VS pensa siano in .h non sono evidenziate nel file .cpp. Non riesco a determinare alcuna differenza nelle funzioni (stessa visibilità, stessa intestazione e file sorgente), tranne forse il thread su cui sono chiamati. Qualche idea sul perché VS pensi che un codice sia in .h piuttosto che in .cpp?Visual Studio 2015 Copertura del codice File errato
risposta
Apparentemente, anche se VS 2015 supporta la funzione C++ 11 non-static data member initializers (viene compilato correttamente), lo strumento di copertura soffoca questa funzione. Ecco l'MCVE. Sto usando VS 14.0.24720.00 Update 1. Per riprodurre, compilare questo programma quindi ottenere la copertura del codice eseguendolo utilizzando uno Generic Test. Se x
viene inizializzato, lo strumento di copertura cerca il codice per il costruttore nel file .h. Se si estrae = 0
, identifica correttamente la definizione del costruttore come in .cpp. Nel mio codice prodotto, non era il costruttore, ma le funzioni apparentemente casuali che lo strumento di copertura pensavano erano definite nel file .h. La correzione, nel mio caso, era solo per spostare l'inizializzazione dei membri dei dati nella lista di inizializzazione del costruttore.
//.h
class Test
{
public:
Test();
~Test();
void Func1();
void Func2();
void Func3();
int x = 0;
};
.
// .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;
}
- 1. Strumento copertura codice/filiale per Visual Studio 2015
- 2. Test di copertura del codice in Visual Studio 2010? Come?
- 3. Strumento di copertura del codice per Visual Studio TDD Project
- 4. Visual Studio 2015 slow
- 5. Impossibile eseguire l'analizzatore dell'analisi del codice in Visual Studio 2015
- 6. Cosa sono "Correzioni del codice Roslyn" in Visual Studio 2015?
- 7. Copertura del codice in Studio Android
- 8. Visual Studio 2015 Apertura file molto lenta?
- 9. Crea file apk utilizzando Visual Studio 2015
- 10. Visual Studio 2015 non risponde
- 11. Copertura del codice con nUnit?
- 12. Visual Studio 2015 .jar reference
- 13. minima Visual Studio versione per Visual Studio 2015 soluzione
- 14. Visual Studio 2015 schiantarsi intermittenza
- 15. LargeAddressAware Visual Studio 2015 C#
- 16. visual studio 2015 sublime theme
- 17. SSDT per visual studio 2015
- 18. Visual Studio 2015 che non rileva Visual Studio 2010
- 19. Impossibile aprire Package.appxmanifest in Visual Studio 2015
- 20. Fake Broken in Visual Studio 2015
- 21. Visual Studio 2015 JavaScript Comportamento strano Intellisense
- 22. Creazione del diagramma del database in Visual Studio 2015
- 23. Visual Studio 2015 - Schema del database del progetto SQL Server
- 24. Riduci margine sinistro in Visual Studio 2015
- 25. Modello di progetto per Visual Studio 2015
- 26. È possibile aggiornare facilmente Visual Studio Community 2015 a Visual Studio Professional 2015
- 27. Visual Studio 2015 - Javascript ES6 non funziona
- 28. Bootstrap Intellisense Manca Visual Studio 2015
- 29. vbcs.cache/edb.log bloccato da Visual Studio 2015
- 30. Visual Studio 2015 non viene avviato
[mcve] sarebbe di aiuto. Stai usando le funzioni basate su modelli? – AndyG
Sono d'accordo. Nessuna funzione basata su modelli. – Jeff
Il progetto x64 o x86? Ricordo che ci sono problemi con x64. – AndyG