Unit Testing è l'obiettivo primario di MVC Pattern?

Di recente in un'intervista, una delle domande era "Perché utilizziamo MVC?" Ho appena risposto che è molto più vicino a come sono molti dei sistemi del mondo reale! Ha spiegato i vantaggi che ha quando si tratta di manutenibilità, scalabilità ecc. Ma non ne erano convinti e alla fine mi hanno detto che MVC viene utilizzato principalmente in quanto "consente un facile test unitario".

Anche se so che il loro è un punto valido, dubito ancora che sia la ragione principale perché (i) anche se decido di non scrivere Unit Testcases, MVC è una scelta probabile (ii) Molti sistemi GUI in cui sono presenti Test Unit Unit non lo fanno seguire MVC.

Quindi la domanda è "L'Unità di Test è l'obiettivo primario del modello MVC?"

EDIT: suppongo che potrebbero menzionare la facilità di Test Driven Development / scrivere NUnit Testcases. Questo perché possiamo scrivere testcase per il Modello (a condizione che la Vista rifletta esattamente i cambiamenti di stato del Modello), per favore correggimi se sbaglio.

L'obiettivo principale sarebbe la "separazione delle preoccupazioni", poiché il modello, la vista e il responsabile del trattamento hanno tutti responsabilità distinte.

L' autore del documento originale Xerox PARC afferma che:

Lo scopo essenziale di MVC è quello di colmare il divario tra il modello mentale dell'utente umano e il modello digitale che esiste nel computer.

Se il test unitario fosse l'obiettivo primario, si sarebbe in grado di visualizzare facilmente i test unitari. Uno sguardo al panorama dei progetti / quadri di unit test rivelerebbe che è del tutto contrario all'affermazione fatta. In genere si utilizzano test di integrazione e funzionali per testare la vista.

Secondo me, la risposta è un "no" fermo. Forse questo è stato il principale vantaggio che è stato osservato in questa specifica organizzazione, ma non lo definirei "obiettivo primario".

Immagino che non sarebbe così difficile implementare MVC in un certo senso, è incredibilmente difficile da testare l'unità (diamine - il modo in cui l'ho fatto per la prima volta era difficilmente testabile).

D'altra parte, si potrebbe dire che praticamente qualsiasi modello (escludendo cose come Singleton) facilita i test unitari, poiché spesso promuovono il disaccoppiamento - ma è il loro "obiettivo primario"? Quasi.

MVC (proprio come la maggior parte dei modelli di progettazione noti) era in circolazione prima che diventassero noti i test unitari. Il libro GoF è stato pubblicato nel 1994 - e stavano solo documentando i modelli che sono stati in uso per anni (se non decenni) prima. (E non vi è alcuna menzione del test unitario in esso.) Riguardo al test unitario, non riesco a individuare un momento esatto in cui è diventato "pubblico" - L'ho letto personalmente in articoli relativi alla Programmazione estrema e nel primo libro di XP uscì nel 1999.

Quindi ovviamente i test unitari non potrebbero essere l'obiettivo principale di inventare / documentare modelli - mentre è giusto affermare che i pattern, se applicati bene, facilitano notevolmente i test unitari.

Penso di no, la facilità di test delle unità è uno dei vantaggi, ma fa parte di una raccolta di vantaggi quando si utilizza MVC insieme ai motivi elencati. Dire che c'è un unico motivo principale per usare MVC è un errore. Sembra che la società in questione scelga MVC per facilitare i test unitari, quindi pensano che sia la ragione principale. Personalmente le mie ragioni per usare MVC sono la sua semplicità rispetto ai moduli web che rende più facile la progettazione e la manutenzione, ma ogni individuo / azienda avrà le proprie ragioni per utilizzare qualsiasi tecnologia.

Nel mondo ASP.NET MVC, molti miglioramenti ad ASP.NET sono stati inclusi nel framework stesso. Lo scopo principale di questo modello di progettazione è quello di isolare la logica aziendale dall'interfaccia utente al fine di concentrarsi su una migliore manutenibilità, una migliore testabilità e una struttura più pulita per l'applicazione.

ASP.NET MVC ha alcune funzionalità che lo rendono l'opzione migliore per scegliere se hai bisogno di una o più delle seguenti opzioni:

• Un elevato livello di controllo sull'HTML generato : a differenza dei moduli Web, le visualizzazioni in ASP.NET MVC eseguono il rendering dell'HTML esattamente come gli si dice. Di recente, i moduli Web sono stati migliorati in quest'area ma non hanno ancora il livello di controllo di MVC.

• Test di unità più semplici : con ASP.NET MVC, è molto semplice seguire schemi di test come lo sviluppo guidato dai test (TDD). A causa del complesso ciclo di vita degli eventi in Web Form, oltre a un framework basato sul controllo, TDD è molto più semplice con MVC.

• Separazione delle preoccupazioni : si riferisce al fatto che tutti gli aspetti del sistema siano chiaramente separati l'uno dall'altro. A causa del modello che implementa, un'applicazione MVC è divisa in parti discrete e liberamente legate (modello, viste e controller), che ne facilita la manutenzione.

Alcuni degli altri vantaggi sono:

• Il modello MVC stesso semplifica la gestione della complessità separando chiaramente la funzionalità dell'applicazione in tre parti principali, il modello, la vista e il controller.

• Le applicazioni Web ASP.NET MVC non utilizzano lo stato di visualizzazione o moduli basati su server. Ciò rende il framework MVC ideale per gli sviluppatori che desiderano il pieno controllo sul comportamento di un'applicazione. Lo stato di visualizzazione può diventare molto grande, il che è un problema per dispositivi come smartphone che funzionano su reti lente (la trasmissione di tutte queste informazioni può essere molto lenta). In una pagina Web Form, potresti averne solo uno per pagina. Questa è una restrizione piuttosto importante. In MVC non esiste tale restrizione, ovvero puoi avere tutti gli elementi che desideri.

• ASP.NET MVC offre un supporto migliore per lo sviluppo test-driven (TDD).

• ASP.NET MVC funziona bene per le applicazioni Web supportate da grandi team di sviluppatori e per i web designer che necessitano di un elevato grado di controllo sull'HTML. ASP.NET Elaborazione richieste MVC