Unit Test di grandi azioni del controllore

Secondo me le azioni dovrebbero essere relativamente piccole e delegare il lavoro ad altri oggetti. Le azioni dovrebbero (di nuovo, a mio parere) essere semplicemente responsabili per quanto segue:

1. Ricezione della richiesta
2. Delega il lavoro ad altri oggetti
3. Restituisce il risultato nel formato corretto

Se lo fai, il test unitario diventa molto più facile attraverso l'uso di oggetti finti e Ingiustizia delle dipendenze. Ogni oggetto può quindi essere testato in modo indipendente.

Posso scrivere un breve esempio di codice più tardi, se necessario.

Se un metodo è troppo grande per un efficace test unitario, il che significa che molto probabilmente fa troppe cose per un metodo, quindi ci sono due approcci che puoi adottare:

1. Dividi il metodo in diversi metodi da chiamare in sequenza
2. Parti astratte della sua funzionalità dietro altri metodi

Nella tua domanda ti sembra di concentrarti su 1, ma la maggior parte delle volte 2 sarà l'opzione migliore, e in questo caso sei già a conoscenza dei problemi che 1 causa- dovresti effettuare chiamate extra dal browser al server, ad esempio.

Esistono due modi per estrarre metodi, sia su metodi privati della stessa classe, sia su metodi pubblici su un'altra classe. I metodi privati non aiutano con i test unitari, quindi generalmente finché si è in grado di creare classi coerenti per i metodi estratti che hanno senso e seguono i principi SOLID, allora questa è la soluzione migliore. Questo è molto comune in MVC, motivo per cui la gente parla di avere controller sottili - il lavoro pesante è svolto dalle classi di servizio a cui i controller chiamano.

Da lì, puoi usare la consueta tecnica di test unitario di mocking per testare i tuoi metodi ora molto più piccoli in isolamento dalle loro dipendenze.