TDD kurallarına göre birim testleri üretim kodundan önce yazılmıştır, peki ya beton (alaysız) kablolu nesneler arasındaki etkileşimi uygulayan Entegrasyon testlerinden ne haber?
Ünite testlerinden önce veya sadece "kablolamayı" test etmek için üretim kodundan sonra yazılmalı mı?
Kabul veya fonksiyonel testlerden bahsetmediğimi, ancak düşük seviyeli entegrasyon testlerinden bahsettiğimi unutmayın.
Yanıtlar:
Rspec Kitabı , diğer BDD kaynaklarının yanı sıra, şöyle bir döngü önerir:
Özünde, süreç:
While behaviour required
Write an integration test for a specific behaviour
While integration test failing
Write a unit test to fulfil partial behavior
While unit test failing
Write code to make unit test pass
Commit
While refactoring can be done
Refactor
While unit test failing
Write code to make unit test pass
Commit
Push
Feragatname: Aklımda bunun en iyi kod ve ürüne yol açtığına dair hiçbir şüphe yok, ancak zaman alıcı olabilir. Entegrasyon testlerinin her zaman geçmesi gerektiğini söylemek söz konusu olduğunda veri ve determinizm konusunda her türlü zorluk vardır. Her koşulda uygun değildir; bazen kapıdan bir şeyler çıkarman gerekir.
Bu, ideal bir süreç göz önünde bulundurularak büyük olduğunu söyledi. Size ödün vermeniz gereken bir nokta verir.
Gerçek proje bana ünite testleri yazmanın mümkün olmadığını gösterdi, daha sonra entegrasyon ve hatta ters yön yanlış bile oldu :-) Bu yüzden, genellikle entegrasyon testleriyle birlikte ünite testleri yazıyorum.
Niye ya? Her iki tür testi de nasıl gördüğümü yazmama izin verin:
Birim testleri - Vikipedi ve tüm bilgilerin yanı sıra birim testleri , tasarımınızı daraltmanıza , modelinizi ve ilişkilerinizi geliştirmenize yardımcı olur . Akış basittir: yeni proje / yeni bileşen yazmaya başladığınızda, çoğu zaman bir çeşit PoC yapıyorsunuzdur . İşiniz bittiğinde, her zaman uzun yöntemlere, uzun sınıflara, tutarlı olmayan yöntemlere ve sınıflara vb. Sahip olursunuz.
Birim testleri, yukarıda açıklanan sahte (başka bir bileşene bağımlılık olmadan) sınıflarını kullanarak gerçek birim testi yaptığınız zaman, test edilemez niteliktedir. Test edilemeyen kodun temel işareti, testlerin büyük bir kısmıdır; çünkü birçok bağımlılıkla (veya durumlarla) dalga geçmek zorunda kalırsınız.
Entegrasyon testleri - doğru ve çalışma testleri size, yeni bileşeninizin (veya bileşenlerinin) birlikte veya diğer bileşenlerle birlikte çalıştığını söylüyor - bu genel tanımdır. Ben entegrasyon testleri çoğunlukla tanımlamak için yardımcı olduğunu tespit ettik senin bileşeni nasıl kullanılacağını akış gelen tüketici tarafında .
API'nizin dışardan mantıklı gelmediğini söylediği için bu gerçekten önemlidir.
Peki, sonra birim testlerini ve entegrasyon testlerini yazdığımda ne oldu?
İyi sınıflar, net tasarım, iyi yapıcı, kısa ve uyumlu yöntemler, IoC hazırlığı vb. Aldım. Bireysel bir müşteri / tüketici sınıfını, örneğin entegrasyon veya GUI ekibinin geliştiricisine verdiğimde, API'mı unbian göründüğü için kullanamadı. , tuhaf. Kafası karışmıştı. Bu yüzden API'yi kendi bakış açısına göre tamir ettim ama aynı zamanda birçok testi tekrar yazmak zorunda kaldım, çünkü yöntemleri ve bazen de API'nin nasıl kullanılacağı akışını değiştirmek için zorlandım.
Peki, daha sonra entegrasyon testleri ve birim testleri yazdığımda ne oldu?
Kesin akışım var, iyi bir kullanılabilirlik Benim de sahip olduğum büyük sınıflar, tutarlı olmayan kodlar, günlük kaydı yok, uzun yöntemler. Spagetti kodu
Benim tavsiyem nedir?
Aşağıdaki akışı öğrendim:
Ünite / entegrasyon testi hakkında küçük sunumlar yaptığımı unutmayın , iskeletin tanımlandığı slayt # 21'e bakınız.
Birim Testleri , bir uygulamadaki mümkün olan en küçük test edilebilir bit yazılımını test etmek ve işlevselliğini test etmek için kullanılır. Her ünite, uygulamanın parçalarına veya daha büyük bileşenlerine birleştirilmeden önce ayrı olarak test edilir.
Entegrasyon Testlerinin geldiği yer burasıdır :
Bu parçaların bir araya getirilmesi sırasında önceden test edilmiş birimlerden oluşan yeni oluşturulan parçaları test ederler. En iyi örnek, uygulamanın kendisini yazarken testleri bu noktada yazmak olacaktır.
Entegrasyon testlerini birim testlerine çok benzer olarak görme eğilimindeyim. Bunun üzerine kodun bir alt kümesini kara kutu olarak görüyorum. Yani entegrasyon testleri sadece daha büyük bir kutu.
Onları üretim kodundan önce yazmayı tercih ederim. Bu, henüz hangi kabloları bağlamadığımı ya da nesnelerin etkileşimindeki ayrıntıları biraz değiştirdiğimi hatırlamama yardımcı olma avantajına sahiptir.
Kabul testlerinin yanı sıra, üçüncü taraf sistemler veya bileşenlerle iyi bir şekilde bütünleştiğini doğrulamak için yalnızca bir uygulamanın sınırlarına entegrasyon testleri yazma eğilimindeyim.
Buradaki fikir, üçüncü tarafın uygulamanızın ihtiyaç duyduğu şeyle konuşma biçiminden çeviri yapan ve bu çevirmenleri gerçek dış sisteme karşı test eden adaptör nesneleri oluşturmaktır. Bu testi ilk mi yoksa son testi mi yaptığınız, normal birim testlerinizden daha az önemli olduğunu düşünüyorum çünkü
TDD tarafından sağlanan tasarım anlayışı burada çok fazla farketmez, çünkü tasarım önceden bilinir ve genellikle karmaşık bir şey yoktur, sadece bir sistemden diğerine şeyleri eşlersiniz.
Ele almak istediğiniz modül / sisteme bağlı olarak, kısa bir TDD geri besleme döngüsüne gerçekten iyi uymayan çok fazla keşif, yapılandırma kontrolü, örnek veri hazırlığı gerekebilir.
Bununla birlikte, adaptörünüzü kademeli olarak küçük güvenli adımlarla oluşturmaktan daha rahat hissediyorsanız, kesinlikle ilk teste girmenizi tavsiye ederim, zarar görmez.
Bu yaklaşımın örneklerini burada bulabilirsiniz: http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html (6. paragraf) http://blog.8thlight.com/eric- smith / 2011/10/27 / şu-not-yours.html
Böylece ilk cevabı kabul edecektim ama silindi.
Özetlemek gerekirse
Belirli bir yinelemede:
Entegrasyon düzeyinde test edilebilirliği garanti etmek için 1 ve 2 iken entegrasyon testlerini aklınızda bulundurun.
Entegrasyon testlerinin mutlaka 3. adımda baştan sona yazılması gerekmez, kısmen 1. ve 2. adımlar arasında yazılabilir.
Birim testleri kod ayrık blok sınamak içinde projeniz.
Entegrasyon testleri, kodunuzun diğer kodla nasıl etkileşimde bulunduğunu test eder: başka bir deyişle, kodunuzun arayüzünü test eder .
Bir arabirimin arkasındaki kodu geliştirirken birim testleri yaz.
Arabirimi veya arabirimi uygulayan kodu geliştirirken tümleştirme testlerini yazın.
Bu, bazen bir projenin entegrasyon testlerini çok geç yazacağınız anlamına gelir, çünkü çalışmanın büyük kısmı ara yüzün arkasındadır: örneğin, bir derleyici, birkaç mantık katmanını uygulayan belirli bir web servisi veya .. iç mantık
Bununla birlikte, bir dizi REST servisi uyguluyorsanız veya veri modelini yeniden yapılandırıyorsanız ve XA işlemlerine destek ekliyorsanız, hemen hemen tümleştirme testlerini geliştirmeye başlayacaksınız, çünkü çalışmanızın çoğu ara yüze odaklanmış olsun. REST API veya programın veri modelini nasıl kullandığı.