Diller Arası Test Odaklı Geliştirme

Kısa soru: Birden çok dile yayılan bir projede Test Odaklı Geliştirme'yi nasıl takip ediyorsunuz?

Özellikle, JavaScript ve PHP kullanan bir web uygulaması yazıyorum ve TDD ilkelerini takip etmek istiyorum, ancak bunları nasıl entegre edeceğimden emin değilim. JS ve PHP bölümleri için ayrı test paketleri çalıştırıyor muyum ve sunucu yanıtlarını taklit etmek için JS paketindeki alayları kullanıyor muyum? Her iki bileşeni tek bir seferde birim test etmek için bir teknik var mı?

Bu, Test Odaklı Geliştirme konusundaki ilk deneyimimdir, bu yüzden onu daha az göz korkutucu hale getirme konusunda paylaşabileceğiniz herhangi bir tavsiye harika olurdu. Bunu seçmemizin nedeni, bir prototipi bitirir bitirmez gereksinimler değişti ve beni tasarımımı değiştirmeye zorladı. Başladığımı anladım, baştan itibaren yerleşik regresyon testi ile daha genişletilebilir kod yazmak istiyorum.

PHP testlerimi SimpleTest ve JavaScript testlerimi JsTestDriver'da yazıyorum. Nesne yönelimli paradigmalara alışkınım, bu yüzden PHP'de birkaç sınıfım var ve prototip paletini kullanarak JavaScript'te benzer bir şey yapıyorum. Ben de okumaya başladım Python TDD hakkında bu kitabı ve JavaScript TDD hakkında bu bir , ama ben gördüm her gelen, bu Selenyum veya başka bir web sürücüsü gibi bir şey kullanmanın (tam olarak dışını bir uygulamayı test tarif yok TDD tam yığın geliştiriciler için kesilmiyor mu?

Her iki bileşeni tek bir seferde birim test etmek için bir teknik var mı?

Bu aslında birim testin tersi olacaktır - özellikle TDD tarzında birim testi, bileşenlerinizi ayrı ayrı test etmek anlamına gelir . Böylece cevap evet, "JS ve PHP bölümleri için ayrı test paketleri çalıştırın ", aksi takdirde birim test değil TDD değil.

Elbette, otomatik entegrasyon testleri "her iki bileşeni de tek seferde" test edebilir ve daha önce bahsettiğiniz araçları (Selenyum gibi) tam olarak kullanabilirsiniz. Ancak bunlar, TDD döngüleri dışında geliştirilen daha karmaşık testlerdir.

Önemli olan TDD ve ATDD'yi ayırt etmektir . Buradaki AT, " kabul testleri" anlamına gelir ve bu, ilk olarak tüm yığını test etme olasılığı olan bir kabul testiyle başladığınız gelişmeyi ifade eder. Buna bazen "dışarıdan test odaklı geliştirme" de denir. İnsanlar TDD hakkında konuştuğunda, "T" muhtemelen özellikle birim testlere atıfta bulunur .

Birim testlerinin önemli bir parçası, test edilen birimi bağımlılıklarından izole etmektir. Bu size iki önemli avantaj sağlar:

• Testlerinizi son derece hızlı yapabilirsiniz, böylece onları çok kısa bir geri bildirim döngüsünün parçası olarak çok sık çalıştırabilirsiniz. Bunları çalıştırmak yerine, her saat, tüm küçük değişikliklerden sonra tüm birim testlerinizi yapabilmeniz gerekir, böylece bu değişikliğin bir şey kırıp kırmadığı hakkında anında geri bildirim alırsınız.

• Testleriniz aynı anda çok spesifik davranışları hedefleyebilir. Bunlardan biri başarısız olursa, testin gösterdiği hatanın neredeyse doğasını neredeyse anında belirleyebilmelisiniz.

Bu izolasyonun önemi nedeniyle, testlerin otomatik olarak dil sınırlarınızın sizi zorladığından çok daha küçük birimlerle sınırlanmasını isteyeceksiniz. Zor ve hızlı bir kural olmasa da, genellikle tek bir sınıfın test edilebilir bir birim olmasını beklersiniz. TDD açısından, dil sorunu aşağı yukarı ilgisizdir.

Öte yandan, ATDD yapmak istiyorsanız, bunun için özellikle kaynaklara baktığınızdan emin olun (genellikle BDD'nin bir parçası olarak yapılır, bu yüzden bunu hedefleyen araçlara da bakın). Selenyum gibi bir şeyin doğal olarak uygun olacağı yer burasıdır. Genellikle, ATDD yaparken hala birim testleri yazıyorsunuz ve aslında her kabul testini geçmek için, birim testleriyle de uygulanmasını test edebilirsiniz. Bu nedenle, ATDD yapmak isteseniz bile, birim testlerinin nasıl yazılacağını anlamak hala önemlidir.

Ayrıca uygulamanın tüm yığını için TDD kullanmak zorunda değilsiniz. Bir geliştirme yöntemi olarak TDD, bir uygulamanın mantık bölümleri için daha uygundur. Daha fazla deneysel dokunuş gerektiren parçalar, örneğin ön ucun tasarımı, belirli etkileşimler veya veritabanı etki alanı, son sürüm olup olmadığını henüz bilmediğiniz için geleneksel bir tarzda daha iyi yapılır.

Ancak uygulamanın mantığı gelecekte değişmemelidir ve eğer öyleyse çok korkunç gereksinim sürünme ile karşı karşıyasınız. Bu, TDD'nin nihai hedefi olan kodda her değişiklik yaparken bir dizi regresyon testinin güven vermesini mükemmelleştirir.

Bob Amca bu yolu benden daha iyi açıklıyor. https://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html