Birim Testi, MVC Kalıbının birincil amacı mı?

Son zamanlarda bir röportajda, sorulardan biri 'Neden MVC kullanıyoruz?' Sadece gerçek dünya sistemlerinin çoğunun ne kadar yakın olduğuna cevap verdim! Sürdürülebilirlik, Ölçeklenebilirlik vb. Söz konusu olduğunda sahip olduğu faydaları açıkladı. Ancak ikna olmamışlar ve sonunda MVC'nin esas olarak 'kolay Birim Testine olanak tanıdığı' için kullanıldığını söylediler.

Onların geçerli bir nokta olduğunu bilsem de, bunun ana nedeni olup olmadığından şüpheliyim çünkü (i) Birim Testcasları yazmamaya karar versem bile, MVC olası bir seçimdir (ii) Birim Testcas'larının olmadığı birçok GUI sistemi MVC izleyin.

Yani soru 'Birim Testi MVC Modelinin birincil hedefi mi?'

EDIT: Test güdümlü geliştirme / NUnit Testcases yazma kolaylığı bahsetmiş olabilir sanırım. Bunun nedeni Model için test senaryoları yazabilmemizdir (Görünümün Modelin durum değişikliklerini tam olarak yansıtması şartıyla) -Yanlışsam lütfen beni düzeltin.

Birincil amaç, model, görüş ve denetleyicinin hepsinin ayrı sorumlulukları olduğu için “endişelerin ayrılması” olacaktır.

Orijinal Xerox PARC Raporu hazırlayan belirtiyor:

MVC'nin temel amacı, insanın zihinsel modeli ile bilgisayarda var olan dijital model arasındaki boşluğu kapatmaktır.

Eğer birim test birincil hedef olsaydı, görünümleri kolayca birim test edebilirdi. Birim test projelerinin / çerçevelerinin manzarasına bir bakış, yapılan iddiaya oldukça aykırı olduğunu ortaya çıkaracaktır. Biri tipik olarak görünümü test etmek için entegrasyon ve fonksiyonel testler kullanır.

Benim düşünceme göre, cevap sağlam bir 'hayır'. Belki de bu özel organizasyonda gözlenen temel faydaydı, ama ben buna 'birincil hedef' demem.

MVC'yi bir şekilde uygulamak o kadar da zor olmayacaktı, ünite testini cehenneme zor (heck - ilk kez yaptığım şekilde neredeyse test edilemezdi).

Öte yandan, çoğu zaman ayrışmayı teşvik ettikleri için hemen hemen her modelin (Singleton gibi şeyler hariç) birim testini kolaylaştırdığını söyleyebiliriz - ama bu onların 'birincil hedefi' mi? Zorlukla.

MVC (tıpkı bilinen tasarım modellerinin çoğunda olduğu gibi), birim testleri bilinmeden önce yoldaydı. GoF kitabı 1994 yılında yayınlandı - ve daha önce yıllardır (onlarca yıl olmasa da) kullanılan kalıpları belgeliyorlardı. (Ve içinde birim testten bahsedilmiyor.) Birim testi hakkında, ne zaman "genel" olduğu hakkında kesin bir zaman bulamıyorum - Ben şahsen Extreme Programming ve ilk XP kitabı ile ilgili makalelerde okudum 1999 yılında çıktı.

Dolayısıyla, birim testi, kalıpları icat etme / belgelemenin ana amacı olamazdı; ancak, kalıpların iyi uygulandığında birim testini büyük ölçüde kolaylaştırdığını söylemek adil olur.

Hayır, ünite testinin kolaylığı faydalardan biri, ancak listelediğiniz nedenlerle birlikte MVC kullanırken faydaların bir koleksiyonunun parçası olduğunu düşünüyorum. MVC kullanmak için tek bir birincil neden olduğunu söylemek bir hatadır. Söz konusu şirketin birim testini kolaylaştırmak için MVC'yi seçtiği anlaşılıyor, bu nedenle bunun birincil neden olduğunu düşünüyorlar. Kişisel olarak MVC kullanma nedenlerim, tasarım ve bakımı kolaylaştıran web formlarına kıyasla basitliğidir, ancak her bireyin / şirketin herhangi bir teknolojiyi kullanmak için kendi nedenleri olacaktır.

ASP.NET MVC dünyasında, ASP.NET'te birçok iyileştirme çerçeveye dahil edilmiştir. Bu tasarım modelinin temel amacı, uygulama için daha iyi sürdürülebilirlik, gelişmiş test edilebilirlik ve daha temiz bir yapıya odaklanmak için iş mantığını kullanıcı arayüzünden izole etmektir.

ASP.NET MVC, aşağıdakilerden birine veya daha fazlasına ihtiyacınız olup olmadığını seçmek için en iyi seçenek haline getiren belirli özelliklere sahiptir:

• Oluşturulan HTML üzerinde yüksek düzeyde kontrol : Web Formlarından farklı olarak, ASP.NET MVC'deki Görünümler tam olarak söylediğiniz gibi HTML oluşturur. Son zamanlarda, Web Formları bu alanda geliştirildi, ancak MVC'nin sahip olduğu kontrol seviyesi hala yok.

• Daha kolay birim testi : ASP.NET MVC ile test odaklı geliştirme (TDD) gibi test modellerini takip etmek çok kolaydır. Web Formlarındaki karmaşık olay yaşam döngüsü nedeniyle, kontrol tabanlı bir çerçevenin üzerinde TDD, MVC ile çok daha kolaydır.

• Endişelerin ayrılması : Bu, sistemin tüm yönlerinin birbirinden açıkça ayrılması anlamına gelir. Uyguladığı desen nedeniyle, bir MVC uygulaması ayrık ve gevşek bağlı parçalara (model, görünümler ve kontrolörler) bölünür ve bu da bakımını kolaylaştırır.

Diğer avantajlardan bazıları:

• MVC deseninin kendisi, uygulamanın işlevselliğini model, görünüm ve denetleyici olmak üzere üç temel parçaya ayırarak karmaşıklığın yönetilmesini kolaylaştırır.

• ASP.NET MVC web uygulamaları görünüm durumunu veya sunucu tabanlı formları kullanmaz. Bu, MVC çerçevesini bir uygulamanın davranışı üzerinde tam kontrol isteyen geliştiriciler için ideal hale getirir. Görüntüleme durumu çok büyük olabilir, bu da yavaş ağlar üzerinden çalışan akıllı telefonlar gibi cihazların sorunudur (tüm bu bilgilerin iletilmesi çok yavaş olabilir). Web Formları sayfasında, her sayfada yalnızca bir tane olabilir. Bu oldukça büyük bir kısıtlama. MVC'de böyle bir kısıtlama yoktur - yani, istediğiniz kadar öğeye sahip olabilirsiniz.

• ASP.NET MVC, test odaklı geliştirme (TDD) için daha iyi destek sağlar.

• ASP.NET MVC, büyük geliştirici ekipleri tarafından desteklenen web uygulamaları ve HTML üzerinde yüksek düzeyde kontrole ihtiyaç duyan web tasarımcıları için iyi çalışır. ASP.NET MVC İstek İşleme