Ho un controllore che implementa una semplice operazione Aggiungi su un'entità e reindirizza alla pagina di dettagli:Unità test di un controllore in ASP.NET MVC 2 con RedirectToAction
[HttpPost]
public ActionResult Add(Thing thing)
{
// ... do validation, db stuff ...
return this.RedirectToAction<c => c.Details(thing.Id));
}
Questa grande opera (utilizzando il RedirectToAction da l'assembly MvcContrib).
Quando eseguo il test dell'unità, desidero accedere al ViewData restituito dall'azione Dettagli (così posso ottenere la chiave primaria della cosa appena inserita e dimostrare che è ora nel database).
Il test ha:
var result = controller.Add(thing);
Ma risultato qui è di tipo: System.Web.Mvc.RedirectToRouteResult
(che è un System.Web.Mvc.ActionResult
). Non ha ancora eseguito il metodo Dettagli.
Ho provato a chiamare ExecuteResult
sull'oggetto restituito passando in un mocked up ControllerContext
ma il framework non era soddisfatto della mancanza di dettagli nell'oggetto deriso.
Potrei provare a inserire i dettagli, ecc. Ecc., Ma il mio codice di test è molto più lungo del codice che sto testando e sento di aver bisogno di test unitari per i test unitari!
Mi manca qualcosa nella filosofia di testing? Come posso testare questa azione quando non riesco a raggiungere il suo stato restituito?
Grazie - che aiuta sicuramente ad evitare le difficoltà con il framework durante i test. Quindi, seguendo questo idioma avrei dei test unitari per il DBService che dimostrano che posso aggiungere cose e un test unitario per il controller che dimostra che le sue chiamate salvano sul servizio. Ma non ho davvero dimostrato che la cosa passata nel controller finisca nel database. Forse potrei farlo con un sacco di regole di derisione più complesse ... ma questo non sembra giusto, è un bel po 'di piastra di prova per una semplice operazione. –
Beh, determinare lo scopo e lo sforzo da mettere nei test e su cosa testare, ecc., È qualcosa con cui ho difficoltà. Penso che dovresti provare a separare i test in due categorie: test unitari e test di integrazione. I test unitari dovrebbero testare solo unità di funzionalità molto piccole, come i test precedenti. I test di integrazione dovrebbero guardare a come tutto si integra, magari coprendo una piccola user story che hai. Preferirei fare i test di integrazione il più vicino possibile all'utilizzo "reale", ad esempio eseguendo WatiN e facendo effettivamente clic su un paio di collegamenti. Non c'è bisogno di prendere in giro lì affatto. – rmac
Se testate il vostro DBService, dimostrerete che funziona. Quindi, si dovrebbe assumere che possa e gestirà correttamente le chiamate al database. Quindi se il tuo controller usa questo servizio, sai che funzionerà. Con il framework mock, è possibile convalidare i parametri che vengono passati ai metodi di servizio e questo è sufficiente. Penso che rmacfie abbia ragione, forse stai cercando di testare troppo più a fondo. Il test dell'unità dovrebbe coprire solo un'azione, non un intero processo. –