Esistono tre modi per organizzare i test unitari: Test per Fixture, Class o Feature. Ma l'attributo NUnit per TestClass si chiama TestFixture. Ci sono ragioni storiche per questo?Perché testFixture anziché TestClass?
Il motivo storico principale è che NUnit ha iniziato la vita come porto diretto da JUnit e Junit lo ha chiamato test di prova.
NUnit 1.0 era prima del mio tempo, ma mi è stato detto che era iniziato rinominando tutti i file .java in JUnit in file .cs e cercando di compilare. È stato riparato da lì e è stata aggiunta una UI. Quando mi sono iscritto a NUnit 2.0 c'era ancora un metodo in NUnit 1.0 chiamato IsVisualAgeForJava poiché JUnit aveva un comportamento speciale per quel momento.
In NUnit 2.0 il nostro obiettivo era rendere NUnit più .NETish. Quindi abbiamo aggiunto gli attributi e un mucchio di altre cose. Tutti noi provenivamo da ambienti java e lavoravamo con JUnit da anni. Sembrava abbastanza naturale usare [TestFixture].
Ora che me lo chiedi, ho appena controllato.
Un dispositivo di prova è lo stato di base fisso che deve essere stabilito prima dell'esecuzione dei test, in modo tale che i risultati siano prevedibili e ripetibili. Nei framework di test unitari, utilizziamo gli attributi/metodi SetUp e TearDown per creare/distruggere il dispositivo di test (ad esempio, inizializzare le variabili di istanza con gli oggetti giusti).
Rispetto la risposta di Mike Two, ma vorrei affermare che il team di NUnit si è sbagliato molto, e l'uso di [TestFixture] è una verruca semantica sul volto di NUnit. Una classe di test non è un apparecchio. Da quello che ho scoperto riguardo a JUnit, non ho trovato alcun riferimento a una classe di test come a un dispositivo di test, né ho trovato molte discussioni su "test fixtures" riferiti alle classi di test. Piuttosto, tutta la discussione di JUnit/xUnit sugli apparecchi riguarda l'installazione e la demolizione, che, naturalmente, sono i metodi più comuni usati per configurare i proiettori di prova.
Si noti che in NUnit 2.5 è possibile rimuovere l'annotazione [TestFixture].
Aggiornamento: (luglio 2012)
Stavo leggendo il Libro e cetriolo a pagina 99, l'autore Matt Wynne spiega l'origine di utilizzare "fixture". Cito:
C'è una lunga tradizione (provenienti dal mondo dell'hardware, dove attrezzature di prova origine) di chiamare il collegamento tra il sistema di test e il sistema in prova un appuntamento fisso. Questo è il ruolo del "codice collante" a cui abbiamo fatto riferimento in questo libro come codice di automazione. Il framework di test FIT utilizza questo significato del termine. Alcuni strumenti di test delle unità (come NUnit) hanno ulteriormente confuso il problema facendo riferimento alla classe del caso di test stesso come a un dispositivo. Così tanto per un linguaggio onnipresente! (Wynne & Hellesoy, 2012)
Sono d'accordo con te. È stato un errore. Una volta lì è difficile riprenderlo. Tuttavia penso che ci fosse un comportamento simile in JUnit al momento. Potrei sbagliarmi del tutto. Era tutto all'inizio del 2002 e potrei ricordarlo in modo errato. In ogni caso sei corretto affermando che una classe di test e una fixture sono cose diverse. –
Grazie Mike Due, sono sempre affascinato dalle storie leggendarie dietro i progetti nel nostro mestiere. Capisco anche che se non mi piace, non dovrei lamentarmi ma presentare una patch. Mi chiedo solo se sono troppo pedante perché nessun altro ha apportato questo cambiamento a NUnit fino ad oggi. – ybakos
Ho pensato di cambiarlo un paio di volte. Colpisco un muro di problemi con la compatibilità all'indietro.Ho interrotto regolarmente il lavoro di NUnit anni fa, quindi non intendo cambiarlo in futuro. –