TDD ile yankılanan bir YES (ve birkaç istisna dışında)
Tartışmalı bir sorun değil, ancak bu soruya 'hayır' cevabını veren herhangi birinin TDD'nin temel bir kavramının eksik olduğunu iddia ediyorum.
TDD'yi izlerseniz , benim için cevabın cevabı evet . Değilse, hayır makul bir cevaptır.
TDD’deki DDD
TDD, genellikle size ana faydalara sahip olarak belirtilir.
- Savunma
- Kodun sağlanması davranışını değiştirebilir ancak değiştiremez .
- Bu, yeniden yapılanmanın hiç bu kadar önemli bir uygulamasına izin vermez .
- Bu TDD'yi kazandınız ya da almayın.
- dizayn
- Bir şeyin ne yapması gerektiğini, uygulamadan önce nasıl davranması gerektiğini siz belirlersiniz .
- Bu genellikle daha bilinçli uygulama kararları anlamına gelir .
- belgeleme
- Test paketi şartname (gereksinimler) dokümantasyonu olarak hizmet etmelidir .
- Bu amaçla testlerin kullanılması, dokümantasyon ve uygulamanın her zaman tutarlı bir durumda olduğu anlamına gelir - birindeki değişiklik, diğerindeki değişiklik anlamına gelir. Gereksinimleri ve tasarımları ayrı kelime dokümanlarında saklayın.
Uygulamadan ayrı sorumluluk
Programcılar olarak, nitelikleri bir anlam yükü ve alıcılar ve bir tür genel gider olarak belirleyici olarak düşünmek çok caziptir.
Ancak nitelikler bir uygulama detayıdır; düzenleyiciler ve alıcılar, programları gerçekten çalıştıran sözleşmeye bağlı arabirimlerdir.
Bir nesnenin şunu yapması gerektiğini hecelemek çok daha önemlidir
Müşterilerinin durumunu değiştirmesine izin ver
ve
Müşterilerinin durumunu sorgulamasına izin ver
o zaman bu durumun gerçekte nasıl saklandığı (hangi özelliğin en yaygın olduğu, ancak tek yol olmadığı).
Gibi bir test
(The Painter class) should store the provided colour
TDD'nin dokümantasyon kısmı için önemlidir .
Sonunda uygulamanın önemsiz (nitelik) olması ve savunma yardımı yapmaması gerçeği , testi yazarken sizin tarafınızdan bilinmemelidir.
Gidiş dönüş mühendisliği eksikliği ...
Sistem geliştirme dünyasında kilit sorunlardan biri gidiş-dönüş mühendisliği eksikliğidir 1 - bir sistemin geliştirme süreci, eserler (belgeler, kodlar) çoğunlukla tutarsız olan ayrık alt işlemlere bölünmüştür.
1 Brodie, Michael L. "John Mylopoulos: kavramsal modellemenin dikildiği tohumlar." Kavramsal Modelleme: Temeller ve Uygulamalar. Springer Berlin Heidelberg, 2009. 1-9.
... ve TDD bunu nasıl çözdü?
Öyle dokümantasyon sistemi ve onun kod özellikleri her zaman tutarlı olmasını sağlar TDD parçası.
Önce tasarım, sonra uygulayın
TDD'ye önce başarısız kabul testini, ancak daha sonra geçmelerine izin veren kodu yazın.
Üst düzey BDD içinde önce senaryolar yazıp geçtik.
Ayarlayıcıları ve alıcıyı neden dışlamalısınız?
Teoride TDD'de bir kişinin testi yazması, diğeri testi geçmek için kodu uygulamasında mükemmel bir şekilde mümkündür.
Öyleyse kendinize sorun:
Bir sınıfa yönelik sınavları yazan kişi, alıcılardan ve ayarlayıcıdan bahsetmelidir.
Alıcı ve ayarlayıcılar bir sınıfa ortak bir arayüz olduğundan, cevap açıktır ki evet , veya bir nesnenin durumunu ayarlama veya sorgulamanın bir yolu olmayacak.
Açıkçası, önce kodu yazarsanız, cevap çok net olmayabilir.
İstisnalar
Bu kuralın bazı belirgin istisnaları vardır - açık bir şekilde uygulama detayı açık olan ve açıkça sistemin tasarımının bir parçası olmayan fonksiyonlar.
Örneğin, yerel bir yöntem 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
Veya buradaki özel işlev square():
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
Veya public, sistem bileşeninin tasarımında yazım gerektiren bir arabirimin parçası olmayan diğer bir işlev .