Ha senso rendere statico la classe di prova dell'unità?

Question

Ho usato NDEPER sulla mia base di codice e mentre il mio codice reale sembra passare a pieni voti, il mio codice di prova unitario potrebbe usare molto lavoro. Uno dei suggerimenti che NDEPED ha fatto è stato la conversione di molte delle mie classi di test unitarie in classi statiche a causa di un alto grado di separazione tra i test. Sembra che questo possa fare a meno di non condividere lo stato tra i test e consentire loro di funzionare ulteriormente in qualsiasi ordine. Dovrei convertire le mie classi di test unitaria in classi statiche?

Condividendo lo stato tra i metodi di prova nella stessa FIXA TEST e, naturalmente

Answer 1

Intrigante! Non ho mai visto nessuno applicare l'analisi NDEPER per testare i progetti prima. Mentre i test unitari devono essere considerati cittadini di prima classe della base di codice, in genere non sono distribuiti con l'applicazione e come tali non sono visualizzati con gli stessi vincoli architettonici (FXCOP, NDEPER, ecc.). Ad un certo livello sono d'accordo con questo approccio, la qualità dei test deve essere convalidata, ma non riesco a vedere quale vantaggio uno strumento può fornire qui oltre all'identificazione delle preoccupazioni di accoppiamento di classe che verrebbero anche identificate nel codice di produzione.

Per quanto riguarda NUNIT, in genere crea un'istanza di una singola istanza di TestFixture per tutti i metodi di prova in quella classe di test. Stato è Condiviso tra i test, e questo è buono e cattivo.

Bene: lo stato che richiede tempo per creare può essere impostato quando viene impostato il dispositivo di prova.

Bad: lo stato che dovrebbe essere ripristinato tra i test dipende da te per correggere tra i test.

Se NUNIT supporta metodi statici per i test e se hai bisogno di uno stato all'interno del dispositivo di test, questi campi dovranno essere statici. In realtà è davvero spaventoso perché lo stato dei tuoi test è condiviso per la vita dell'appdomain di test.

La chiave è utilizzare gli attributi NUNIT per l'inizializzazione / lo smontaggio del dispositivo e testare. Non utilizzare mai costruttori o finalizzatori per l'inizializzazione del dispositivo in quanto non è possibile controllare quando il framework NUNIT crea la tua classe.

Answer 2

Se i tuoi test non devono essere eseguiti in un ordine particolare o non dipendono dal codice iniziale, puoi renderli statici.

Ricorda che questa non è una ricetta per il successo.