Cosa dovrei cercare quando valuto le librerie e gli strumenti di test delle unità?

Question

Cosa dovrei cercare quando valuto le librerie e gli strumenti di test delle unità?

#1 da (3 voti)
#2 da (2 voti)

8

Sono in procinto di scegliere nuovi strumenti di test delle unità per il progetto che verrà presto avviato. Ce ne sono molti!

I requisiti di base che ho sono che può eseguire test su almeno Windows e Linux, è compatibile con C ++ / C ++ 03, può eseguire test in parallelo (ad esempio, per sfruttare i processori multi-core) ed è in grado di essere eseguito dalla riga di comando. Ma questi sono requisiti piuttosto ampi e non hanno ristretto il campo.

Per provare a farlo, sto esaminando potenziali trucchi e insidie di diversi tipi di implementazioni. Ad esempio, se volessi utilizzare un motore di test delle unità in un linguaggio di livello superiore come Python, produrrebbe comunque output formattati come i test delle unità C? Il mio intento principale qui è quello di utilizzare gli stessi strumenti di archiviazione e di report per i test dei risultati C ++ e Python.

Mi chiedo anche se sia necessario avere un motore specifico per eseguire i test, o è sufficiente averli integrati nel nostro motore di integrazione continua (buildbot).

Queste due preoccupazioni sono sopra valide? Di che altro dovrei preoccuparmi quando valuto i motori di prova delle unità?

unit-testing continuous-integration multi-platform

posta Didier Trosset 20.01.2012 - 14:57

fonte

2 risposte

Leggi altre domande sui tag unit-testing continuous-integration multi-platform

C'è un caso in cui non esiste una sostituzione ragionevole per il modello di progettazione singleton? [duplicare] Qualche buona pratica per un team agile distribuito? [chiuso]

score 3 · Answer 1

Ho utilizzato entrambi Google Test e Boost Test . Entrambi sono framework xUnit, funzionano su Unix e Windows e sono maturi. Ho finito con l'utilizzo di Google Test a causa di Google Mock poiché volevo un framework di simulazione. O dovrebbe funzionare bene su buildbot.

Personalmente, voglio che il framework di test unitario sia minimo e veloce. Voglio molti test e quindi li voglio eseguire in un arco di tempo ragionevole. Personalmente mi piace usare il framework principale per un linguaggio invece di un mega strumento, ma questo è personale. Se lo si desidera, è possibile esaminare i test di iterazione continui: ogni volta che si salva un file, viene eseguito automaticamente i casi di test da cui dipende il file.

Potresti sempre scrivere una classe di interfaccia per il tuo test unitario, consentendo così un rapido ed efficace cambio di framework.

score 2 · Answer 2

Le mie esperienze coinvolgono CruiseControl.NET e Team Foundation Build. Sono uno sviluppatore .NET anch'io. Questi provengono dalle mie esperienze e includono solo le esperienze in cui sono stati testati come parte del processo di creazione, quindi se non corrispondono al tuo ambiente, mi dispiace.

I'm also wondering if it's necessary to have a specific engine to run the tests, or is it enough to have them integrated into our continuous integration engine

Se stai facendo una build ad ogni check-in, è possibile avere build innescate prima che la build precedente abbia finito di girare. Come vuoi gestire situazioni come questa? Ad esempio, se occorrono 30 minuti per eseguire l'intera suite di test e il codice viene controllato ogni 15 minuti, vuoi saltare alcune build? Salta alcuni test? Impilarli, costruirli in ordine e tornare da Bob che ha rotto la build con il suo check-in 5 ore fa?

Team Foundation Build può utilizzare più core per build e test con il 2010 (le versioni precedenti potevano usare solo core multipli per build C ++). CruiseControl.NET può eseguire thread separati, ma leggendo la documentazione , sembra che ogni progetto possa essere sul proprio thread , ma che non puoi avere più thread per progetto (potrei sbagliarmi). Non abbiamo mai avuto una macchina multi-core per le build negli ambienti in cui ho lavorato, quindi non posso parlare di quanto siano buone / giuste / cattive (o che io sia sbagliato).

In un precedente datore di lavoro, abbiamo incluso gli script Python nella build, ma non avevamo alcuna configurazione di testing per testare Python. NANT è stato utilizzato per i componenti .NET.

I'm also wondering if it's necessary to have a specific engine to run the tests

Non ho mai avuto il tempo di farlo, ma in un precedente datore di lavoro (abbiamo venduto il software "shrinkwrap"), avevamo molti bug che erano specifici del sistema operativo (e talvolta specifici del service pack), quindi uno dei miei obiettivi era quello di impostare più macchine di prova con diversi sistemi operativi (sia 32 + 64 bit e tutti i vari tipi di desktop e server Windows da XP in poi). Le macchine di compilazione erano macchine WinXP semplici o vecchie (o virtuali) perché quello era tutto l '"hardware" che ci era stato concesso dai gestori. Invece, tutti i test sono stati eseguiti sulla macchina di compilazione. Abbiamo anche impostato suite di convalida come raccolte di test unitari, sebbene non fossero eseguiti per aggiornamenti minori.