TDD hakkında birçok şey okudum ama hala şüphelerim var. Örneğin, bu sınıf diyagramları var:
Basit bir örnek, sadece TDD ve sahte nesneler hakkında bilgi edinmek için.
Önce hangi testi yazmalıyım? Ürün , sonra Hat ve son, Sipariş ? Bunu yaparsam, Siparişi test etmek için Çizgi ve Ürün kullanmalı mıyım yoksa Mock Nesneleri mi kullanmalıyım? Sahte Nesneleri ne zaman kullanmalıyım? XP ve TDD ile UML kullanmalı mıyım?
Bu şeyleri henüz anlamıyorum.
Yanıtlar:
Şemadan yola çıkarak, Ürün test edilecek işlevselliği olmayan aptal bir veri sınıfıdır. Bu yüzden bağımlılık merdiveni için önce Line ve sonra Order için (ve TDD stili) testler yazmaya başladım. Daha yüksek seviye sınıflarında çalışmaya başlamadan önce (yani alt seviyeye bağlı olan) daha düşük seviye sınıflarınızın test edilmesi genellikle mantıklıdır. Bu, yakalama hatalarını daha verimli hale getirir.
Sahte nesneleri kullanmanız gerekip gerekmediği test edilen sınıfın gerçek bağımlılıklarına bağlıdır. Bunlar, testleriniz için gerekli olan herhangi bir veri / durumla kolayca başlatabileceğiniz ve ayarlayabileceğiniz basit sınıflarsa, alay etmeye ihtiyacınız yoktur. (Buradaki örnek tasarımınız için durum böyle görünüyor.) Bununla birlikte, bağımlılıklardan herhangi birinin başlatılması zorsa / geniş bağımlılıklara sahipse / istenmeyen yan etkilere sahipse / DB gibi harici bir kaynağa bağlıysa, o zaman mantıklıdır bunun yerine sahte bir nesne kullanmak.
Burada sahte nesnelere fazla ihtiyaç duymuyorum. Başkaları tarafından belirtildiği gibi, çoğunlukla bağımlılıkların kurulması zorsa bunlara ihtiyacınız vardır.
Örneğin, denetleyicileri test ettiğimizde ve başka bir denetleyiciye çağrı yapılması ve bilgilerinin bir kısmını bir çerezde depolaması gereken bir kullanıcı girişine ihtiyaç duyduğumuzda onları Ruby on Rails projelerinde kullandık. Bu durumda, belirli bir erişim ayrıcalığı hakkında soru sorulduğunda, oturum açmış bir kullanıcının true değerini alay etmek yararlı olur.
Normalde test için test edilen sistemi / nesneyi izole etmek istersiniz, böylece bunun dışında olan her şeyi alay edersiniz. Sınıf diyagramınızı kullanarak, bir sipariş nesnesini test ederken, çizgi nesnesi için bir sahte kullanın. Line'ı test ederken, Sipariş ve Ürün için bir sahte kullanın. Ürünü test ederken Line için sahte kullanın.
"TDD öncelikle kaynak kodunuzun tamamen birim test edilmesini sağlayan bir yan etkisi olan bir tasarım tekniğidir" - Scott W. Ambler
Fikir, birim testleri yazarak tasarımı bulmaktır. Sizin durumunuzda, TDD'nin amacını yenen bir tasarıma zaten sahipsiniz gibi görünüyor (tasarımınızın nihai olduğunu varsayarak).
Alay ile ilgili. Alay etmek istiyorsanız, Line testlerini yazarken sahte ürün siparişini test ederken sahte olarak önermenizi öneririm. Ama burada aşırıya kaçabilir. Şahsen alaycılığı olabildiğince sınırlamaya çalışıyorum ve harici sınıflara (veritabanı örnekleri gibi) bağımlılıkları ayırmak için kullanıyorum.