Unit Testing e .Net

5

Venendo da uno sfondo di sviluppo nativo, sono abituato ai miei test runner che emettono il file e la linea che ha causato il fallimento del test. Questo mi ha permesso di eseguire i test come una fase post-build, e se qualche test fallisse la build fallirebbe. Inoltre, potrei premere il tasto di scelta rapida e saltare direttamente alla linea di offesa.

Quello che sto scoprendo nel mondo .Net è che nessuno sembra funzionare in questo modo. Sono disposto ad ammettere che forse esiste un modo diverso e migliore di fare le cose in questo universo alternativo, ma mi piacerebbe sapere cos'è. Non voglio avere bisogno di uno strumento esterno (orribile), e non voglio dover ricordare di compilare e quindi eseguire i miei test.

Quello che voglio veramente è quello che avevo sempre: i test falliti fallivano anche la build, e una rapida pressione di un tasto di scelta rapida mi faceva saltare alla prova che non funzionava.

Modifica: dovrei aggiungere che mi piacerebbe vedere una sorta di integrazione con il formato di file csproj di Visual Studio. Avere un compito MSBuild personalizzato sarebbe fantastico, ma sarei perfettamente soddisfatto di un comando console che inserisco in un Exec o AfterBuild.

    
posta moswald 01.06.2011 - 18:41
fonte

4 risposte

0

Poiché nessuno ha spiegato adeguatamente perché vorrei cambiare i miei modi, ho implementato la soluzione da solo. Ho forked xUnit per correggere l'output dalla loro attività di build MSBuild .

    
risposta data 06.07.2011 - 13:58
fonte
2

NAnt è popolare con gli sviluppatori .NET per creare script di build. Puoi usarlo per creare vari build target , come ad esempio: compilare, unit test, eseguire la copertura del codice, test di accettazione, pubblicare ecc.

Puoi impostare le dipendenze tra i target, ad es. il test unitario dipende dalla compilazione, il test di accettazione dipende dal test dell'unità, ecc. Se un bersaglio fallisce, i bersagli dipendenti non vengono eseguiti.

L'output di ciascun target entra in un file di log di build , è lì che puoi registrare gli errori di test.

Con la maggior parte delle attività eseguite dai target di build (ad esempio nunit2 che può essere utilizzato per eseguire test di unità) è possibile specificare failonerror="true" per far fallire la build se non si ottiene il risultato previsto (ad es. tutti i test pass).

    
risposta data 01.06.2011 - 18:56
fonte
0

Se è disponibile, è possibile configurare build wtihin Team Foundation Server. Questo link può aiutare - Configura il tuo sistema di compilazione

    
risposta data 01.06.2011 - 20:01
fonte
0

In precedenza ho funzionato eseguendo nUnit's Console Runner in una fase post-build e poi utilizzando formato di output XML di nUnit e piping che tramite un XSLT utilizza un piccolo file XSL che abbiamo scritto per produrre il file (riga): quale formato per i test falliti.

IIRC Ho sollevato un bug con il team nUnit per farli migliorare l'output XML per renderlo un po 'più semplice - ma questa pagina implica che questo funzioni già. Stai usando l'ultima versione?

    
risposta data 06.07.2011 - 20:21
fonte

Leggi altre domande sui tag