Come testare il controller ASP.NET MVC senza utilizzare il modello di repository

Question

Mi chiedo solo se è possibile testare alcune unità del mio controller Azione in MVC senza utilizzare il modello di repository. Ho sviluppato un sito MVC ASP.NET ma l'ho fatto senza test delle unità nella fase iniziale. Ora voglio dimostrare alcuni test unitari al mio tutor utilizzando potrebbe essere due o più azioni nel mio controller. La maggior parte delle mie azioni logiche ottengono i dati dal database e un controller riceve i dati da diverse tabelle, le azioni in un controller vengono lette da una tabella diversa. che penso possa essere testato usando un modello di deposito generico. Come principiante ho scoperto che posso solo testare un codice che non proviene dal database, ma sfortunatamente la maggior parte del codice nel mio controller Le azioni provengono dal database. sto usando lo strumento di test predefinito in Visual Studio e il primo approccio al codice EF per il mio database.
ad esempio mi piacerebbe testare solo le azioni sottostanti senza dover testare altre azioni che si trovano nello stesso controller.

public ActionResult Index() 
    { 
     var model = _db.PhotoGallery; 
     return View(model); 
    } 

Questo è solo per scopo dimostrativo.

Answer 1

Per definizione, un test di unità deve influire solo sul metodo che chiama. Se riesci a trovare un modo per deridere il tuo oggetto _db in modo che tu non stia effettivamente causando un round-trip del database, puoi testare questo metodo che si basa su di esso. Altrimenti no.

Il tuo campo _db è un'interfaccia? Viene fornito tramite iniezione? Se è così, è probabile che tu possa testare questo metodo.

Answer 2

Senza rimuovere la dipendenza diretta dal database nei metodi del controller, non sarà possibile testare questi metodi.

Il modo generale consigliato per eseguire questa operazione consiste nell'utilizzare un contenitore IOC (ad esempio Ninject) in combinazione con MVC che consente di trasferire i dati necessari al costruttore del controller. Quel "oggetto dati" non deve essere legato al database, di solito è solo un oggetto POCO o passato come interfaccia.

Nel test di unità è possibile quindi sostituire queste dipendenze utilizzando un oggetto dati in memoria costruito solo per il test di unità, tipicamente "deriso" utilizzando un quadro di scherno (ad esempio rinoceronte Mocks o Moq).

Utilizzando questo approccio non solo i controllori sono testabili in base all'unità, ma si ritroveranno anche con un codice molto sciolto, un vantaggio che potrebbe essere vantaggioso per lo sviluppo successivo.

Answer 3

Questo è ciò che ha chiamato testable codice :) Quando si esegue il test delle unità, è necessario essere sicuri, che soltanto la ragione della mancanza di prova sta cambiando in SUT (sistema in prova o una classe in fase di test) implementazione. Ovviamente, potrebbe essere interrotto quando l'API di dipendenza cambia (ok, dovresti modificare SUT per usare la nuova API), ma non dovrebbe mai fallire se le implementazioni di dipendenza cambiano. Questo è il motivo per cui si usano beffe e stubbing.

Ma se si vuole prendere in giro la dipendenza, non si dovrebbe crearlo all'interno di SUT. Dovrebbe essere iniettato in SUT (costruttore, proprietà dell'iniezione dei parametri).

Quindi, di nuovo al vostro caso:

• se si vuole avere classe testabile, è necessario iniettare la dipendenza (db)
• dipendenza dovrebbe essere preso in giro
• non costretti ad usare Pattern Repository . Se riesci a prendere in giro la tua classe di db, basta prenderlo in giro.O utilizzare qualsiasi altra astrazione di accesso ai dati