Web Uygulamalarında Test Odaklı Geliştirme için Kaynaklar? [kapalı]

Regresyonları azaltmak ve sürüm kalitesini artırmak için web uygulamalarımızda bazı TDD'yi denemek ve uygulamak istiyorum, ancak otomatik testin web uygulamaları kadar kabarık bir şeyle ne kadar iyi performans gösterebileceğine ikna olmadım.

TDD ve birim testlerini okudum ve denedim, ancak örnekler 'sağlam' ve para birimi dönüştürücüler gibi oldukça basit işlevler.

İçerik yönetimi ve yayın sistemlerinin birim testine yardımcı olabilecek herhangi bir kaynak var mı? Bir alışveriş sepetini / mağazasını (fiziksel ve çevrimiçi ürünler) birim test etmeye ne dersiniz? AJAX?

"Web Test Odaklı Geliştirme" için googling, birkaç yıl öncesine ait hesap makinesine benzer işlev örneklerini kapsayan eski makaleleri veya TDD'nin neden herhangi bir şeyden daha iyi olduğu ile ilgili tartışmaları (herhangi bir örnek olmadan) alıyor.

Büyük sorumluluk reddi: Herhangi bir web uygulaması oluşturmadım veya herhangi bir web uygulamasını test etmedim. Aşağıdakiler, bilgi alanındaki rastgele yürüyüşlerimde absorbe ettiğim bilgilerden sadece birkaçı.

Web uygulamanızı, iş kurallarını ayrı ayrı test edebilecek şekilde oluşturun. Kendinizi iş kurallarını kullanıcı arayüzü üzerinden test ederken bulursanız, yeniden tasarlamayı düşünmenin zamanı gelmiş olabilir.

Kullanıcı arayüzünü test etmek söz konusu olduğunda, iş kurallarınızı öngörülebilir şekillerde yanıt veren sahte uygulamalarla değiştirin.

Yukarıdaki iki kural Bob Martin'in RailsConf 2010'daki konuşmasından alınmıştır . Konuşma, TDD ile ilgili değil ve testten bahsettiği bölüm kısa ve ortada bir yer.

JavaScript test etmek için JsUnit , JSSpec , YUI Test ve kullanıcı arabirimini test etmek için Selenium ve Watir gibi araçlar vardır .

Pragmatik Kitaplık web uygulamaları test kapsayan birkaç kitap var. Test ile etiketlenmiş kitapların listesi http://www.pragprog.com/categories/design adresinde bulunmaktadır . Pragmatic Bookshelf web uygulaması test kitapları esas olarak Ruby ve Rails'e odaklanmıştır, ancak genel olarak uygulanabilir olmalıdır.

Test Odaklı JavaScript Geliştirme , Sinon.js ve Buster.js'nin arkasındaki geliştirici olan Christian Johansen'den (web sitesinden alınan) aşağıdaki konuları kapsayan gerçekten güzel bir kitap :

• Birim testi ve TDD'yi anlama
• Doğru birim test çerçevesinin seçilmesi
• Daha temiz API'ler, modüler ve sağlam JavaScript oluşturma
• Yeniden düzenleme yoluyla kodu sürekli iyileştirme
• Beş pratik TDD oturumu: Ajax, DOM manipülasyonu, Node.js ve daha fazlası
• Dili bilmeyen geliştiriciler için test odaklı JavaScript turu

Şu anda Sinon.js'yi Mocha ile kullanıyoruz, ancak özellikleri gerçekten temiz olduğu için Buster.js'ye geçmeye hazırız!

Bir projede ben kurşun geliştirici kullanmaya karar vermişti Son dönemlerde yaptığım Unity herhalde Birlik kullanımı genellikle TDD eşlik edecek bir web uygulamasıdır - yani alaycı böylece ve TDD büyük bir web uygulamasında basitleştirilmiş edildi.

Birim testi CMS'nin araştırılması muhtemelen çıkmaza yol açabilir, çünkü alay etmek için makul bir şey yoktur. Sayfalara http trafiğini alay etmeden nelerin test edilebileceğini görmüyorum ve bu noktada testin değeri çok az.

Web uygulamaları ile kullanışlı bir kural olduğunu düşünüyorum, karmaşıklığı azaltmak için bir sahte kullanabiliyorsa, o zaman muhtemelen birim test edilebilir.

Böylece bir web uygulamasında veri erişim katmanınızın veya modelinizin farklı bölümlerini test etmek için veritabanınızı taklit edebilirsiniz; görünümü veya kullanıcı arabirimini vb. test etmek için kullanıcı girişini taklit edebilirsiniz.

Python + Django ile web geliştirme için TDD hakkında bir kitap yazdım. TDD'yi hem uçtan uca / fonksiyonel testler (selenyum) hem de alt düzey "birim" testleri ile kapsar. Git'in iş akışınıza nasıl entegre edileceği, bir sunucuya nasıl dağıtılacağı ve otomatikleştirilip test edileceği, sürekli entegrasyon, alaylar ve test izolasyonu ve çok daha fazlası gibi modern geliştirme uygulamalarını da kapsıyorum:

http://www.obeythetestinggoat.com/

(veya http://shop.oreilly.com/product/0636920051091.do )