Best practice per l'impostazione di un progetto Visual Studio per n Test nUnit

Question

In che modo le persone impostano i propri progetti per Visual Studio e come si fa riferimento all'applicazione testabile?

In questo momento ho aggiunto un progetto separato creando un file .dll alla mia soluzione che contiene tutti i casi di test e riferimenti nunit.framework, e fa anche riferimento al file .exe principale direttamente dalla cartella Debug/dove VS genera Il risultato.

Ma non ho idea se sia una buona idea - o quali sono le migliori pratiche, qualcuno vuole condividere le loro pratiche?

Answer 1

Mi sembra abbastanza utile: è possibile distribuire o distribuire l'applicazione senza il test assembly e NUnit, ma testare ancora tutto. Praticamente pratica standard.

Answer 2

Ho usato una cartella separata per tutti i miei test quando li utilizzo all'interno di un progetto. Quindi è possibile rimuovere facilmente la cartella quando si esegue una build effettiva se si sceglie di.

Ho anche fatto quello che stai dicendo con un progetto separato. Penso che vada bene.

Answer 3

In genere, ho una soluzione contenente un numero di progetti senza test di unità in quella soluzione principale: questa è la soluzione che viene creata in modalità di rilascio per una vera build.

Per un progetto specifico, ho una soluzione separata che contiene il progetto che voglio test unitario (e qualsiasi dipendente) e un progetto MyProjectName.UnitTests che ospita tutti i test unitari per quel progetto. Questi progetti di test unitari vengono quindi configurati all'interno di una macchina di integrazione continua per ottenere la build in modalità di debug e quindi eseguire i test.

Funziona bene per me.

Answer 4

Supponendo che il progetto di test sia nella stessa soluzione dei progetti sottoposti a test, un piccolo miglioramento potrebbe essere quello di aggiungere un riferimento al progetto (i) in fase di test anziché al file binario nella cartella Debug.

Oltre a ciò che è stato menzionato qui, spesso utilizzo anche l'attributo InternalsVisibleTo per rendere visibili le classi interne dell'assieme che sto testando all'assieme di test, in modo che possano essere testate direttamente.

A seconda del framework di isolamento scelto, potrebbe essere necessario rendere i componenti interni del proprio assieme visibili ai componenti del framework di isolamento per essere in grado di simulare/interrompere determinati comportamenti interni.

Answer 5

Non penso che ci sia qualcosa di sbagliato nel fornire dll contenenti codice che provi che anche la DLL in un ambiente di produzione funziona ancora all'interno dei parametri stabiliti :). In caso di errori strani è comunque possibile eseguire i test unitari con la DLL di rilascio e vedere se qualcosa si è rotto in un modo strano. Per questo motivo e poiché non mi piace avere il doppio del numero di progetti in una soluzione, preferisco aggiungere una cartella Test in ogni progetto in cui tutto il codice di test unitario va. Semplice ed efficace.

saluti,

Sebastiaan