Qualcuno sta facendo un "vero" TDD con Visual-C ++ e, se sì, come lo fanno? [chiuso]

Test Driven Development implica scrivere il test prima del codice e seguire un certo ciclo :

• Scrivi test
• Verifica test (esegui)
• Scrivi il codice di produzione
• Verifica test (esegui)
• Pulizia del codice di produzione
• Verifica test (esegui)

Per quanto mi riguarda, ciò è possibile solo se la soluzione di sviluppo consente di passare rapidamente dal codice di produzione a quello di test e di eseguire il test per una determinata parte del codice di produzione in modo estremamente rapido.

Ora, sebbene esistano molti Unit Testing Frameworks per C ++ (sto usando Bost.Test atm.) Sembra che non esista davvero nessuna soluzione decente (per C ++ nativo ) di Visual Studio (Plugin) che rende il TDD ciclo sopportabile indipendentemente dalla struttura utilizzata.

"Sopportabile" significa che è un clic per eseguire un test per un determinato file cpp senza dover impostare manualmente un progetto di test separato ecc. "Sopportabile" significa anche che un semplice test inizia (collegamento!) E si esegue molto rapidamente .

Quindi, quali strumenti (plugin) e quali tecniche sono disponibili per rendere possibile il ciclo TDD per lo sviluppo C ++ nativo con Visual Studio?

Nota: sto bene con strumenti gratuiti o "commerciali".

Per favore : nessuna raccomandazione quadro. (A meno che il framework non abbia un plug-in Visual Studio dedicato e si desideri consigliare il plug-in.)

Modifica nota : le risposte finora hanno fornito collegamenti su come integrare un framework di unit test in Visual Studio. Le risorse descrivono più o meno come ottenere la compilazione del framework UT e l'esecuzione dei primi test. Questo è non è ciò che questa domanda è circa. Sono dell'opinione che lavorare davvero in modo produttivo, avendo i Test Unit in una manutenzione manuale (!), Vcproj separato dalle tue classi di produzione aggiungerà così tanto sovraccarico che TDD "non è possibile". Per quanto ne so, non si aggiungono "progetti" extra a una cosa Java o C # per abilitare Unit Test e TDD, e per una buona ragione. Questo dovrebbe essere possibile con C ++ dato gli strumenti giusti, ma sembra (questa domanda riguarda) che ci sono pochissimi strumenti per TDD / C ++ / VS.

Cercando su internet, ho trovato uno strumento, VisualAssert , che sembra mirare nella giusta direzione. Tuttavia, non sembra essere molto diffuso (rispetto a CppUnit, Boost.Test ecc.).

Modifica: vorrei aggiungere un commento al contesto per questa domanda. Penso che faccia un buon riassunto del delineare (parte del) problema: (commento di Billy ONeal )

Visual Studio non utilizza "script di compilazione" ragionevolmente modificabili dall'utente. Un progetto produce un binario. Inoltre, Java ha la proprietà che Java non costruisce mai un binario completo: il binario che costruisci è solo un ZIP dei file di classe. Pertanto è possibile compilare separatamente quindi JAR insieme manualmente (usando ad esempio 7z). C ++ e C # collegano entrambi i loro binari, quindi in generale non puoi scrivere uno script del genere. Il più vicino che puoi ottenere è compilare tutto separatamente e quindi fare due collegamenti (uno per la produzione, uno per i test).

Ho scritto una serie di blog in 5 parti su TDD con C ++ e Visual Studio: parte 1 , parte 2 , parte 3 , parte 4 , parte 5 .

Non sono sicuro del motivo per cui dici che non fai progetti extra in C # per fare TDD, perché è quello che ho sempre fatto con NUnit e sembra tipico di quello che fanno gli altri anche con NUnit. Il motivo è semplice: tenere sempre il codice di prova separato dal codice di produzione. Per C ++ con Visual Studio, ciò significa progetti separati, proprio come per C # e NUnit. Da quello che so del mondo Java, questo è anche comune lì.

Ovviamente, ognuno ha idee diverse su ciò che è "sopportabile" per fare TDD. Ho praticato il metodo che descrivo nel mio post sul blog per anni severi e lo trovo molto sopportabile. Il C ++ è un linguaggio compilato e la compilazione può essere lenta quando il sistema sotto test è altamente accoppiato. Non c'è modo di sfuggire a questo senza refactoring a un design più liberamente accoppiato.

La mia "azione con un clic" è "Crea soluzione". Se si sta costruendo troppo, è sempre possibile scaricare progetti irrilevanti mentre si sta lavorando e quindi Build Solution costruirà solo il sottoinsieme minimo di progetti necessari per essere aggiornati a seguito delle modifiche.

Certo, la natura del tempo di compilazione di C ++ rende questo richiedere un po 'più tempo in ogni ciclo del processo TDD rispetto a NUnit e C #, ma vale la pena ottenere la fiducia dal mio ben collaudato codice C ++. Altrimenti passerò molto più tempo nel debugger. Vorrei essere prudente nell'usare il tuo uso di gmock in quanto può aggiungere sostanzialmente al tempo di compilazione del test. Finora mi sono quasi sempre allontanato con oggetti "finti" leggeri e raramente ho bisogno della piena funzionalità delle beffe. I framework di derisione per C ++ sono fortemente basati su template e questo può aumentare significativamente i tempi di compilazione, quindi dovrebbero essere riservati dove hai davvero bisogno di un finto e un falso semplicemente non lo farà.

Ho preso in considerazione la creazione di una procedura guidata per il progetto di test di unità Boost.Test per automatizzare parte della natura della piastra della caldaia della creazione del progetto di test per il codice di produzione, ma dopo averlo fatto un paio di volte non è poi così difficile eseguirlo manualmente.

Per quanto riguarda le soluzioni con molti (150?) Progetti, ci sono anche modi per far fronte a questo. Uno ovvio è trovare gruppi di progetti correlati e raggrupparli insieme e iniziare a consumarli / pubblicarli come unità. Se hai davvero bisogno di ricostruire / toccare tutti i 150 progetti per le piccole modifiche che stai apportando durante un ciclo TDD, il tuo codice è così fortemente accoppiato che i test unitari probabilmente non faranno molta differenza.

Guardando il link IDE netbeans, trovo il piacere di avere qualcosa che analizza l'output del test e mostra una piccola riga di test in una finestra con un simbolo verde o rosso accanto a qualcosa che pensavo mi sarebbe mancato venendo da NUnit, ma in realtà non è mancato. Ho trovato più utile che la compilazione fallisse semplicemente e quindi potevo fare doppio clic nella finestra degli errori per posizionare il cursore nella posizione dell'asserzione fallita.

Non sto usando Visual-C ++, ma sto eseguendo TDD con C ++, usando googletest e googlemock, con QtCreator come mio IDE. Anni fa ho avuto una configurazione simile con Visual-C ++ ma utilizzando un diverso framework di unit test.

Ciò che ho trovato utile è di separare il progetto in alcuni sottoprogetti.

1. Una libreria statica o dinamica che contiene il 99% del codice sorgente del progetto effettivo.
2. Un progetto che consiste principalmente in un metodo main () per eseguire il normale programma.
3. Un progetto di test che contiene un main () per eseguire il mio framework di test e molti file contenenti test e oggetti finti.

Con questa configurazione, il mio IDE si occupa dell'aggiunta di file a vari progetti e se le dipendenze vengono determinate correttamente, posso eseguire tutti i miei test unitari con una ricostruzione parziale. Al momento l'ho anche configurato per eseguire tutti i miei test immediatamente dopo la compilazione. Anche Jenkins, l'IC che sto utilizzando, esegue e fornisce risultati dei test e dati di copertura.

Potrebbe essere possibile aggiungere un launcher personalizzato nell'IDE per un file per eseguire i test unitari per il file Foo.cpp se ti è capitato di nominare tutti i test unitari per Foo nel dispositivo di test TestFoo. Come impostarlo esattamente per Visual-C ++ non sono sicuro ma penso che sia possibile.

Uso MSTest per testare il codice C ++ nativo.
Ecco il grande post sul blog in questo modo: http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c. aspx

Sì, ci saranno almeno due progetti: uno per l'applicazione stessa, uno per i test.
Invece di creare un terzo progetto con una libreria statica, aggiungo solo il sorgente dell'applicazione al test del progetto, quindi la soluzione è simile alla seguente:

[-] Solution 'Foo'      Foo\Foo.sln
 |-[-] Foo              Foo\Foo\Foo.vcproj
 |  |-[-] include
 |  |  |- foo.h         Foo\Foo\foo.h
 |  |  |- bar.h         Foo\Foo\bar.h
 |  |
 |  |-[-] source
 |     |- foo.cpp       Foo\Foo\foo.cpp
 |
 |-[-] Foo.Tests        Foo\Foo.Tests\Foo.Tests.vcproj
    |                        (Additional include directory: "..\Foo")
    |-[-] include
    |  |- FakeBar.h     Foo\Foo.Tests\FakeBar.h
    |
    |-[-] source
       |-[-] app
       |  |- foo.cpp    Foo\Foo\foo.cpp    -- not in Foo.Tests\
       |
       |-[-] unit-tests
          |- foo_Tests.cpp   Foo\Foo.Tests\foo_Tests.cpp
          |- bar_Tests.cpp   Foo\Foo.Tests\bar_Tests.cpp

Forse un po 'tardi, ma se ho letto correttamente la tua domanda, stai cercando tecniche per migliorare il ciclo TDD? Non è stato menzionato qui, ma hai visto gli eventi post-build in VS?

Le nostre soluzioni sono in genere organizzate (con le dipendenze del progetto mostrate) ...

MAIN-APP > LIB1, LIB2, UNIT-TEST-APP
UNIT-TEST-LIB1 > LIB1
UNIT-TEST-LIB2 > LIB2
UNIT-TEST-APP > UNIT-TEST-LIB1, UNIT-TEST-LIB2

L'evento post-build di MAIN-APP eseguirà UNIT-TEST-APP

L'evento post-build di UNIT-TEST-APP si eseguirà da solo (basta inserire '$ (TargetPath)' come comando da eseguire nell'evento post-build).

(Ciò significa che quando si crea MAIN-APP, i test unitari possono essere eseguiti due volte, ma questo non è stato un problema nel nostro caso!)

Come già detto, sì, c'è un po ' di sforzo nell'impostare questa struttura, ma una volta che è lì, aggiungere test è semplice.

Quindi tutto ciò che devi fare è creare l'app principale e i test unitari verranno eseguiti automaticamente!

Bene, non so se questo aiuta, ma ci sono alcuni fantastici video su TDD di Brett L. Schuchert. Sfortunatamente, non mostra la combinazione "C ++" e "VS", ma

TDD con C # e VS: http://vimeo.com/album/210446

TDD con C ++ ed Eclipse: http://vimeo.com/13240481

Forse puoi risolverlo da quei due.

EDIT: il video C ++ riguarda l'uso del framwork di test CppUTest con Eclipse, ovviamente. Quando l'ho pubblicato ho pensato che dovesse essere facilmente adottato per l'utilizzo in VS. Quindi ho cercato su Google un po 'e ho trovato questo:

http://schuchert.wikispaces.com/tdd.cpp.NotesOnCppUTest

che fornisce informazioni su come utilizzare CppUTest in Visual Studio.

Googletest
Come integrarsi con vc ++

Non hai bisogno di un plugin, il test è solo un altro obiettivo. Non ci sono plugin per generare test con c ++, anche se tu potessi testare cose inutili come le assegnazioni

Non posso commentare gli strumenti C ++ poiché non ho toccato da circa 20 anni (sviluppatore .NET in questi giorni) e immagino che la maggior parte degli strumenti in questi giorni siano per codice gestito ma per quanto riguarda le tecniche ...

Come altri hanno già detto, il codice di test è sempre in un progetto / assembly completamente diverso rispetto al codice di produzione e sì, di solito è necessario mantenere quel progetto da soli, anche se certamente nell'IDE VS questo non è un grosso problema poiché spesso si hanno diversi progetti come parte della tua soluzione comunque.

Il codice di produzione è e deve essere scritto in modo leggermente diverso per TDD. Mentre scrivi prima i test, devi finire per progettare il tuo codice per essere testabile. Questo è tutto un altro argomento in sé, ma può richiedere del tempo e all'inizio sembra molto frustrante, specialmente se i tuoi IDE / strumenti non ti danno un feedback rapido, sborsare per eseguire strumenti da riga di comando per eseguire test è solo dirompente.

Esistono molte tecniche specifiche per rendere testabile il codice, ma la maggior parte di loro si interrompe nel creare piccoli oggetti che non fanno molto, in modo da poterli testare da soli e poter iniettare una versione di prova di alcuni comportamenti in più complessi oggetti. I framework IOC possono aiutare molto qui.

Un libro che potresti trovare utile è; Michael Feathers, che lavora efficacemente con il codice legacy. Questo utilizza più lingue nei suoi esempi e può aiutarti a identificare approcci specifici per adattare in modo sicuro codice / tecniche che non sono stati originariamente progettati per essere testabili.

Piccolo avvertimento: ho bevuto dall'Agile Kool-Aid anni fa: D

Maven non è ampiamente utilizzato in C ++ (tuttavia, viene utilizzato principalmente per Java ma è agnostico in termini di linguaggio) ma è uno strumento molto potente e ti consente di mantenere tutto in un unico progetto (inclusi i test, infatti, che è raccomandato approccio con Maven). Lo suggerisco solo ora, poiché dalle risposte finora sembra che non esista un'alternativa con un plugin VS.

Cercando plugin ho trovato:

http://incubator.apache.org/npanday/

ma non sembra essere ancora molto maturo. Con l'installazione di Maven tutto ciò che dovresti fare per eseguire i test viene eseguito mvn testnella riga di comando.

Se sei interessato, puoi scoprirlo qui e (uno dei) plug-in di supporto C ++ qui (Maven ha un'architettura plug-in, quindi tutto è un plug-in).

Raccomandazione quadro: nel nostro ufficio utilizziamo TestDriven.NET che si integra con Visual Studio. Le classi unittest sono scritte in C ++ / CLI, che possono quindi chiamare per esercitare qualunque codice nativo sia necessario testare. Sì, le classi C ++ / CLI vanno nel loro assembly, quindi un progetto di "testing" aggiunto alle soluzioni.