Kodu genel olarak test etmek kolay değildir. Öyle olsaydı, bunu uzun zaman önce yapardık ve sadece son 10-15 yılda böyle bir şey yapmazdık. En büyük zorluklardan biri, her zaman kapsülleme kırılmadan uyumlu, iyi faktörlü ve test edilebilir kodların nasıl test edileceğinin belirlenmesidir. BDD müdürü neredeyse tamamen davranışa odaklanmamızı önermektedir ve bazı açılardan iç detaylar hakkında bu kadar büyük bir endişe duymanız gerekmediğini düşündürmektedir, ancak bu genellikle test edilmesi oldukça zor olabilir. daha gizli bir şekilde tüm olası sonuçlarla başa çıkmak için testinizin genel karmaşıklığını artırabileceğinden, çok gizli bir şekilde "şeyler" yapan birçok özel yöntem.
Alay etmek belirli bir dereceye kadar yardımcı olabilir, ancak yine de oldukça dışarıdan odaklanmıştır. Bağımlılık Enjeksiyonu da yine alay veya test ikilileri ile oldukça güzel çalışabilir, ancak bu aynı zamanda öğeleri bir arabirim yoluyla veya doğrudan gizli kalmayı tercih edebileceğiniz öğeleri ortaya çıkarmanızı gerektirebilir - bu özellikle isterseniz doğrudur sisteminizdeki belirli sınıflar hakkında iyi bir paranoyak güvenlik seviyesine sahip olun.
Benim için jüri, sınıflarınızı daha kolay test edilebilir olacak şekilde tasarlayıp tasarlamayacağınıza hala karar verdi. Bu, eski kodu korurken yeni testler sağlamanız gerektiğini fark ederseniz sorun yaratabilir. Bir sistemdeki her şeyi kesinlikle test edebilmenizi kabul ediyorum, ancak onlar için bir test yazabilmem için bir sınıfın özel içsellerini - dolaylı olarak bile - ortaya çıkarma fikrinden hoşlanmıyorum.
Benim için çözüm her zaman oldukça pragmatik bir yaklaşım benimsemek ve her bir özel duruma uyacak bir dizi tekniği birleştirmek olmuştur. Testlerim için iç özellikleri ve davranışları ortaya çıkarmak için çok sayıda kalıtsal test ikilisi kullanıyorum. Sınıflarıma iliştirilebilecek her şeyi alay ediyorum ve sınıflarımın güvenliğinden ödün vermeyeceği yerlerde, test amacıyla davranışları geçersiz kılmak veya enjekte etmek için bir araç sunacağım. Kod test etme yeteneğini geliştirmeye yardımcı olacaksa, daha fazla olay odaklı bir arayüz sağlamayı düşüneceğim.
Ben herhangi bir "test edilemez" kodu bulmak nerede , ben şeyler daha test edilebilir hale getirmek için refactor olup olmadığını görmek için bakmak. Sahnelerin arkasına gizlenmiş çok sayıda özel kodunuz olduğunda, genellikle dağılmayı bekleyen yeni sınıflar bulacaksınız. Bu sınıflar dahili olarak kullanılabilir, ancak genellikle daha az özel davranışla ve daha sonra genellikle daha az erişim ve karmaşıklık katmanlarıyla bağımsız olarak test edilebilir. Kaçınılması gereken bir şey, ancak test kodu yerleşik olarak üretim kodu yazmaktır. Bu tür dehşet dahil sonuçlanan " test pabuçları " oluşturmak cazip olabilir if testing then ..., hangi bir test sorunu tamamen çözülmüş ve eksik çözülmüş değil gösterir.
Gerard Meszaros'un xUnit Test Patterns kitabını okumakta fayda var. Muhtemelen önerdiği her şeyi yapmıyorum, ancak başa çıkmak için bazı daha zorlu test durumlarını netleştirmeye yardımcı oluyor. Günün sonunda, tercih ettiğiniz tasarımları uygularken test gereksinimlerinizi karşılayabilmek istersiniz ve nerede ödün vermeniz gerektiğine daha iyi karar verebilmek için tüm seçenekleri daha iyi anlamanıza yardımcı olur.