I test delle unità del modello possono essere veramente indipendenti e come [ASP.NET MVC]

Question

Sono nuovo per l'intera unità di prova, quindi scusate la mia mancanza di esperienza. Ho letto molti materiali che dicono che nessun test dovrebbe dipendere da altri, i test unitari sono completamente indipendenti l'uno dall'altro. Puoi davvero farlo nella realtà? Sto avendo il seguente esempio: ho poche classi di entità che dipendono l'una dall'altra, basate su un certo schema di database (sto usando Linq- a SQL per generarle) Ora, se voglio testare ogni classe di modello che devo costruire un oggetto della classe del modello, costruire un oggetto di prova di ciascuna delle sue dipendenze, assegnarle alle proprietà dell'oggetto e quindi mantenere l'oggetto prima di controllare il contesto e asserire che funzioni effettivamente.

Questo ovviamente rende molto più difficile eseguire test che non dipendano l'uno dall'altro, o che non vengano eseguiti in una sequenza specifica (io non un'istanza di tipo Content da creare prima di avere almeno un'istanza di tipo ContentType) La dipendenza, almeno a livello di modello, è presente e non può essere evitata.

Per favore, mi critichi molto, se pensi che io abbia torto. Voglio imparare.

P.S. Solo per menzionare che sto lavorando su un'app ASP.NET MVC e test con NUnit se questo ha senso

Answer 1

Sì, il test di unità dovrebbe (e può) essere indipendente. Il problema che descrivi riguarda la dipendenza. La dipendenza deve essere risolta utilizzando i framework Injection Dependency (vedere AutoFac, progetti Ninject).

L'altra cosa è che il tuo Database dovrebbe essere deriso usando oggetti finti (vedi Moq, progetti di Rhino Mocks). È necessario testare tutto il codice anche se il database è disconosciuto.

Un'altra cosa è che il test dell'unità dovrebbe testare solo una funzionalità, non tutto il processo.

Answer 2

Ciò che descrivete qui non è test unitario ma test di integrazione. Poiché il modello di dati della tua applicazione è strettamente collegato al database, i tuoi test probabilmente testano la funzionalità del database e non il "datamodel".

Questo è perfettamente soddisfacente: è sufficiente tenere presente che i test di integrazione richiedono l'installazione (nel database del caso) e richiedono più tempo per l'esecuzione.

Probabilmente hai anche dei test unitari per i tuoi controller che possono essere completamente isolati da altri componenti e non hanno bisogno di database per funzionare, questi sono i test unitari di cui parli.

Se non si verifica la funzionalità del database reale, è possibile utilizzare l'oggetto falso/mock per sostituire le classi esterne, infatti i test creati con il progetto MVC iniziale hanno degli oggetti finti arrotolati a mano lungo che fanno esattamente questo.

Un altro modo per "isolare" le vostre dipendenze esterne consiste nel deformare il codice di Linq2Sql con la vostra classe e simulare queste chiamate di classe usando il framework di Mocking.

Answer 3

Sì, puoi davvero farlo nella realtà.

La chiave per essere in grado di isolare ogni unità è in scrittura codice con accoppiamento lento. Assumere una dipendenza dalle classi LINQ a SQL (L2S) non è strettamente accoppiato, il che spiega i tuoi problemi.

Sarebbe meglio definire una serie di interfacce dietro cui è possibile nascondere il codice L2S. Il modello di dominio funziona quindi su tali interfacce anziché direttamente sulle classi L2S.