Ünite testini etkinleştirmek için kodumuzu baştan tasarlamalı mıyız?

Şu anda ekibimizde ünite testine izin vermek için kod tasarımını değiştirmenin bir kod kokusu olup olmadığı veya bir kod kokusu olmadan ne ölçüde yapılabileceği konusunda tartışmalar var. Bu ortaya çıktı, çünkü sadece diğer tüm yazılım şirketlerinde bulunan uygulamaları uygulamaya koymaya yeni başladık.

Özellikle, çok ince olacak bir Web API servisimiz olacak. Başlıca sorumluluğu, web isteklerini / yanıtlarını toplamak ve iş mantığını içeren temel bir API'yi aramak olacaktır.

Bir örnek, bir kimlik doğrulama yöntemi tipi döndürecek bir fabrika yaratmayı planlıyoruz. Asla olacağı somut türden başka bir şey olacağını tahmin etmediğimizden, bir arayüzü miras almasına gerek yok. Ancak, Web API servisini test etmek için bu fabrika ile alay etmemiz gerekecek.

Bu, temel olarak DI'yi kabul etmek için Web API denetleyici sınıfını tasarladığımız anlamına gelir (yapıcısı veya ayarlayıcısı aracılığıyla); denetleyiciyi bu şekilde tasarlamak zorunda kalmamak için Ninject gibi üçüncü taraf bir çerçeve, ancak yine de bir arayüz oluşturmak zorunda kalacağız.

Ekipteki bazı kişiler sadece test yapmak için kod tasarlama konusunda isteksiz görünüyorlar. Bana öyle geliyor ki, eğer ünite testini yapmayı umuyorsanız, biraz uzlaşmanın olması gerekiyor, ama endişelerinin ne kadar gergin olduğunu bilemiyorum.

Sadece açık olmak gerekirse, bu yepyeni bir proje, bu yüzden birim testini etkinleştirmek için kod değiştirmekle ilgili değil; Bu, test edilebilir bir birim olarak yazacağımız kodu tasarlamakla ilgilidir.

Test uğruna kod değiştirme isteksizliği, bir geliştiricinin testlerin rolünü anlamadığını ve uygulamada kuruluştaki kendi rolünü anlamadığını gösterir.

Yazılım işi, işletme değeri yaratan bir kod tabanı sağlama konusunda döner. Acı ve uzun bir deneyimle, test yapmadan önemsiz büyüklükte kod tabanları oluşturamayacağımızı tespit ettik. Bu nedenle, test paketleri işin ayrılmaz bir parçasıdır.

Pek çok kodlayıcı bu ilkeye bağlılık duymaz ancak bilinçaltında asla kabul etmez. Bunun neden olduğunu anlamak kolaydır; Kendi zihinsel kabiliyetimizin sınırsız olmadığı ve aslında, modern bir kod tabanının muazzam karmaşıklığı ile karşı karşıya kaldıklarında şaşırtıcı bir şekilde sınırlı olduğu bilinci, istenmeyen ve kolayca bastırılabilir veya rasyonelleştirilebilir. Test kodunun müşteriye teslim edilmemesi, “temel” işletme koduna kıyasla ikinci sınıf bir vatandaş ve zorunlu olmadığına inanmayı kolaylaştırır. Ve işletme koduna test kodu ekleme fikri pek çok kişiye iki kat rahatsız edici görünüyor.

Bu uygulamanın gerekçelendirilmesinin zorluğu, bir yazılım işinde değerin nasıl yaratıldığının tüm resminin genellikle sadece şirket hiyerarşisindeki yükselişler tarafından anlaşılması gerçeğiyle ilgilidir, ancak bu insanlar teknik olarak ayrıntılı bir anlayışa sahip değillerdir. Testlerin neden elde edilemeyeceğini anlamak için gereken kodlama iş akışı . Bu nedenle, testlerin genel olarak iyi bir fikir olabileceğini garanti eden uygulayıcılar tarafından sıklıkla pasifleştiriliyorlar, ancak "biz böyle koltuk değneklerine ihtiyaç duymayan seçkin programcılarız" ya da "şu an buna vaktimiz yok" vb. İş başarısının bir sayı oyunu olması ve teknik borçlardan kaçınmak, kalite vb. sadece uzun vadede değerini gösterir, bu inançta genellikle çok samimi oldukları anlamına gelir.

Uzun lafın kısası: kodun test edilebilir hale getirilmesi, geliştirme sürecinin önemli bir parçasıdır, diğer alanlardan farklı değildir (birçok mikroçip, yalnızca test amaçlı olarak önemli miktarda öğeyle tasarlanmıştır ), söyledi. Bu tuzağa düşme.

Düşündüğün kadar basit değil. Yıkalım.

• Ünite testleri yazmak kesinlikle iyi bir şey.

FAKAT!

• Kodunuzda yapılacak herhangi bir değişiklik bir hataya neden olabilir. Bu nedenle, kodu iyi bir iş nedeni olmadan değiştirmek iyi bir fikir değildir.

• 'Çok ince' webapi üniteniz için en iyi durum gibi görünmüyor.

• Kod ve testleri aynı anda değiştirmek kötü bir şey.

Aşağıdaki yaklaşımı öneririm:

1. Entegrasyon testlerini yaz . Bu herhangi bir kod değişikliği gerektirmemelidir. Size temel test durumlarınızı verecektir ve yaptığınız herhangi bir kod değişikliğinin herhangi bir hata ortaya koymadığını kontrol etmenizi sağlayacaktır.

2. Yeni kodun test edilebilir olduğundan ve birim ve entegrasyon testlerinin olduğundan emin olun .

3. CI zincirinizin yapı ve dağıtımlardan sonra testler yaptığından emin olun.

Bunları kurduğunuzda, ancak daha sonra test edilebilirlik için eski projeleri yeniden düzenlemeyi düşünmeye başlayın.

Umarım herkes süreçten dersler çıkarır ve testin en çok nerede gerekli olduğu, onu nasıl yapılandırmak istediğiniz ve işletmeye kazandırdığı değer hakkında iyi bir fikir sahibi olur.

EDIT : Bu cevabı yazdığımdan beri, OP mevcut kodda yapılan değişikliklerden değil yeni koddan bahsettiğini göstermek için soruyu netleştirdi. Belki de saf bir şekilde "Ünite testi iyi midir?" Diye düşündüm. tartışma birkaç yıl önce çözüldü.

Birim testlerinde hangi kod değişikliklerinin gerekli olacağını hayal etmek zor, ancak her durumda isteyeceğiniz genel iyi uygulama değildir. Muhtemelen gerçek itirazları incelemek akıllıca olacaktır, muhtemelen itiraz edilen birim test tarzıdır.

Kodun doğal olarak test edilebilir olması için tasarlanması kod kokusu değil; Aksine, iyi bir tasarımın işaretidir. Büyük bir avantaj olarak kolay (daha kolay) test sunan, buna dayanan (örneğin, Model-View-Presenter) bazı iyi bilinen ve yaygın olarak kullanılan tasarım desenleri vardır.

Bu nedenle, daha kolay bir şekilde test etmek için somut sınıfınız için bir arayüz yazmanız gerekirse, bu iyi bir şeydir. Zaten somut bir sınıfınız varsa, çoğu IDE ondan bir arayüz çıkararak çabayı minimum düzeyde tutar. İkisini senkronize etmek biraz daha fazla iş, ancak bir arayüzün yine de fazla değişmemesi gerekiyor ve testten elde edilen faydalar bu ekstra çabadan daha ağır basabilir.

Öte yandan, @MatthieuM olarak. Bir yorumda, kodunuza üretimde kullanılmaması gereken, yalnızca test yapmak amacıyla kullanılmaması gereken belirli giriş noktaları ekliyorsanız, bu bir sorun olabilir.

IMHO, birim testleri oluşturmak için test edilecek kodun en azından belirli özelliklere sahip olması gerektiğini anlamak çok basittir. Örneğin, kod yalıtılmış bir şekilde test edilebilecek ayrı birimlerden oluşmuyorsa, "birim test" kelimesi bir anlam ifade etmiyor bile. Kod bu özelliklere sahip değilse, önce değiştirilmesi gerekir, bu oldukça açıktır.

Teoride, ilk önce bazı SOLID ilkelerini uygulayarak bazı test edilebilir kod birimlerini yazmayı deneyebilir ve daha sonra orijinal kodu değiştirmeden bir test yazmaya çalışabilirsiniz. Ne yazık ki, gerçekten test edilebilir bir kod yazmak her zaman basit değildir, bu nedenle yalnızca testleri oluşturmaya çalışırken tespit edebilecek bazı değişiklikler yapılması muhtemeldir. Bu, ünite testi düşünülerek yazıldığında bile kod için geçerlidir ve "ünite test edilebilirliğinin" başlangıçta gündemde olmadığı yerlerde yazılan kod için kesinlikle daha doğrudur.

Önce ünite testlerini yazarak sorunu çözmeye çalışan iyi bilinen bir yaklaşım var - buna Test Driven Development (TDD) denir ve kodun en baştan test edilebilir hale getirilmesi kesinlikle yardımcı olabilir.

Tabii ki, daha sonra kodun test edilebilir hale getirilmesi için değiştirilmesinin isteksizliği, genellikle kodun ilk önce manuel olarak test edildiği ve / veya prodcution'da iyi çalıştığı bir durumda ortaya çıkar, bu nedenle değiştirmek gerçekten de yeni hataları ortaya çıkarabilir, bu doğru. Bunu hafifletmek için en iyi yaklaşım ilk önce bir regresyon test paketi oluşturmaktır (genellikle kod bazında sadece çok az değişiklikle uygulanabilir) ve ayrıca kod incelemeleri veya yeni manuel test oturumları gibi eşlik eden diğer tedbirler. Bazı iç organların yeniden tasarlanmasının önemli hiçbir şeyi bozmadığından emin olmak için yeterince güvenmeniz gerekiyor.

Yaptığınız (doğrulanmamış) iddia ile konuya katılıyorum:

Web API servisini test etmek için bu fabrika ile alay etmemiz gerekecek

Bu mutlaka doğru değil. Testleri yazmak için birçok yol vardır ve orada olan mocks içermeyen birim testleri yazmak için yollar. Daha önemlisi, işlevsel veya entegrasyon testleri gibi başka tür testler de vardır. Çoğu zaman bir OOP programlama dili olmayan bir "arayüzde" bir test dikişi "bulmak mümkündür interface.

Daha doğal olabilen alternatif bir test dikişi bulmanıza yardımcı olacak bazı sorular:

• Farklı bir API üzerinden ince bir Web API yazmak isteyecek miyim ?
• Web API ile temel API arasındaki kod çoğaltmasını azaltabilir miyim? Biri diğeri açısından üretilebilir mi?
• Tüm Web API'sini ve temel API'yi tek bir "kara kutu" birim olarak değerlendirebilir ve her şeyin nasıl davrandığı hakkında anlamlı bir şekilde iddiada bulunabilir miyim?
• Web API'sinin gelecekte yeni bir uygulamayla değiştirilmesi gerekiyorsa, bunu nasıl yaparız?
• Gelecekte Web API'sinin yerine yeni bir uygulama geldiyse, Web API'sinin müşterileri bunu fark eder mi? Öyleyse nasıl?

Yaptığınız bir başka doğrulanmamış iddia DI ile ilgili:

Web API denetleyici sınıfını DI'yi (yapıcısı veya ayarlayıcısı aracılığıyla) kabul edecek şekilde tasarlıyoruz; bu, denetleyicinin bir bölümünü yalnızca DI izin vermek ve aksi takdirde gerek duymadığımız bir arabirim uygulamak için tasarlıyoruz ya da üçüncü bir taraf kullanıyoruz. Ninject gibi bir yapı, denetleyiciyi bu şekilde tasarlamaktan kaçınmak için yine de bir arayüz oluşturmak zorunda kalacağız.

Bağımlılık enjeksiyonu mutlaka yeni bir şey yaratmak anlamına gelmez interface. Örneğin, bir kimlik doğrulama belirteci nedeninde: Programlı bir şekilde gerçek bir kimlik doğrulama belirteci oluşturabilir misiniz ? Daha sonra test böyle belirteçler oluşturabilir ve bunları enjekte edebilir. Bir belirteci doğrulama işlemi bir tür şifreleme sırrına mı dayanıyor? Umarım bir sırrı kodlamamışsındır - umarım bir şekilde depodan okuyabilirsin ve bu durumda test vakalarında farklı (iyi bilinen) bir sır kullanabilirsin.

Bu asla yeni bir şey yaratmaman gerektiğini söylemek değildir interface. Ancak, bir test yazmak için tek bir yol veya bir davranış sergilemek için tek bir yol olmaktan kaçının. Kutunun dışında olduğunu düşünüyorsanız, genellikle kodunuzun minimum şekilde kısıtlanmasını gerektiren ve yine de istediğiniz efekti veren bir çözüm bulabilirsiniz.

Bu yeni bir proje olduğu için şanslısınız. Test Driven Design'ın iyi kod yazmak için çok iyi çalıştığını tespit ettim (bu yüzden ilk başta yapıyoruz).

Endam ile ön gerçekçi girdi verileri ile bir kod verilmiş parça çağırmak ve sonra amaçlandığı gibi, sen çok erken sürecinde API tasarımı yapmak olduğunu kontrol edebilirsiniz gerçekçi çıkış verilerini almak ve bir alma şanslarının yüksek olduğu nasıl kullanışlı tasarım, uyum sağlamak için yeniden yazılması gereken mevcut kodla engellenmediğiniz için. Ayrıca akranlarınız tarafından anlaşılması kolaydır, böylece sürecin başlarında tekrar iyi tartışmalar yapabilirsiniz.

Yukarıdaki cümleydeki "kullanışlı" ifadesinin yalnızca ortaya çıkan yöntemlerin çağrılmasının kolay olduğu değil, aynı zamanda entegrasyon testlerine katılması kolay temiz arayüzler alma ve makbuz yazma eğiliminde olduğunuz anlamına da dikkat edin.

Bir düşün. Özellikle akran değerlendirmesi ile. Tecrübelerime göre zaman ve emek yatırımı çok hızlı bir şekilde iade edilecektir.

Kodda değişiklik yapmanız gerekirse, kod kokusu budur.

Kişisel deneyimlerime göre, kodum için testler yazmak zorsa, kod kötüdür. Kötü kod değil çünkü tasarlandığı gibi çalışmıyor veya çalışmıyor, kötü çünkü neden çalıştığını hemen anlayamıyorum. Eğer bir hatayla karşılaşırsam, bunu düzeltmek için çok acı verici bir iş olacağını biliyorum. Kodun tekrar kullanılması zor ve imkansız.

İyi (Temiz) kod, görevleri bir bakışta (veya en azından iyi bir görünüşte) kolayca anlaşılan daha küçük bölümlere ayırır. Bu küçük bölümleri test etmek kolaydır. Ayrıca, alt bölümler hakkında oldukça emin olduğumda yalnızca kod tabanının bir kısmını test eden testler yazabilirim (yeniden kullanım, daha önce test edildiği gibi burada da yardımcı olur).

Kodu, test edilmesi kolay, yeniden yapılandırılması kolay ve baştan tekrar kullanmak kolaydır; değişiklik yapmanız gerektiğinde kendinizi öldürmezsiniz.

Tamamen temiz bir prototip olması gereken bir projeyi tamamen temiz bir kod haline getirirken bunu da yazıyorum. Kısmen işe yarayan bir şeyi kırma korkusuyla herhangi bir şeye dokunmaktan korkmaktan, saatlerce bir ekrana bakmak yerine, en baştan ve refactor kötü kodundan en kısa zamanda elde etmek çok daha iyidir.

Birim test edilemeyen kod yazmanın kod kokusu olduğunu iddia ediyorum . Genel olarak, kodunuz ünite test edilemiyorsa, modüler değildir, bu da anlaşılmasını, sürdürülmesini veya geliştirilmesini zorlaştırır. Belki kod, yalnızca entegrasyon testi açısından anlamlı olan bir tutkal koduysa, ünite testi için entegrasyon testinin yerine geçebilirsiniz, ancak entegrasyon başarısız olduğunda bile sorunu izole etmeniz gerekecektir ve ünite testi harika bir yoldur. yap.

Diyorsun

Bir kimlik doğrulama yöntemi türü döndürecek bir fabrika oluşturmayı planlıyoruz. Asla olacağı somut türden başka bir şey olacağını tahmin etmediğimizden, bir arayüzü miras almasına gerek yok. Ancak, Web API servisini test etmek için bu fabrika ile alay etmemiz gerekecek.

Bunu gerçekten takip etmiyorum. Bir şey yaratan bir fabrikaya sahip olmanın nedeni fabrikaları değiştirmenize ya da fabrikanın kolayca ne yarattığını değiştirmenize izin vermektir, bu nedenle kodun diğer bölümlerinin değişmesine gerek yoktur. Kimlik doğrulama yönteminiz asla değişmeyecekse, fabrika işe yaramaz kod şişmesidir. Bununla birlikte, testte üretimden farklı bir kimlik doğrulama yöntemine sahip olmak istiyorsanız, testte üretimden farklı bir kimlik doğrulama yöntemi döndüren bir fabrikaya sahip olmak harika bir çözümdür.

Bunun için DI veya Mocks'a ihtiyacınız yok. Farklı kimlik doğrulama türlerini desteklemesi ve bir şekilde bir yapılandırma dosyasındaki veya ortam değişkenindeki gibi bir şekilde yapılandırılabilmesi için fabrikanıza ihtiyacınız var.

Aklıma gelen her mühendislik disiplininde, iyi veya daha yüksek kalite seviyelerine ulaşmanın tek yolu var:

Tasarımda muayene / test yapmak için.

Bu, inşaat, talaş tasarımı, yazılım geliştirme ve imalatta geçerlidir. Şimdi, bu, testlerin her tasarımın değil inşa edilmesi gereken dayanak olduğu anlamına gelmez. Ancak, her tasarım kararında, tasarımcıların test maliyetlerine etkileri konusunda net olmalı ve ticaret ile ilgili bilinçli kararlar almalıdırlar.

Bazı durumlarda, manuel veya otomatik (örneğin Selenyum) testi, tek başına kabul edilebilir test kapsamı sağlarken, Birim Testlerinden daha uygun olacaktır. Nadir durumlarda, neredeyse tamamen denenmemiş bir şeyi oraya atmak da kabul edilebilir. Ancak bunların, dava kararlarıyla bilinçli olması gerekir. Bir "kod kokusu" testini hesaba katan bir tasarıma çağrı yapılması ciddi bir deneyim eksikliğine işaret ediyor.

Birim testinin (ve diğer otomatik test türlerinin) kod kokularını azaltma eğiliminde olduğunu ve kod kokularını ortaya koydukları tek bir örnek düşünemiyorum. Birim testleri genellikle sizi daha iyi kod yazmaya zorlar. Kolayca test edilen bir yöntemi kullanamıyorsanız, neden kodunuzda daha kolay olmalı?

İyi yazılmış birim testleri, kodun nasıl kullanılması gerektiğini size gösterir. Bunlar çalıştırılabilir bir belge şeklidir. Tuhaf bir şekilde yazılı, anlaşılamayan aşırı uzun testler gördüm. Bunları yazma! Sınıflarınızı ayarlamak için uzun sınavlar yazmanız gerekirse, sınıflarınızın yeniden düzenlemeye ihtiyacı vardır.

Birim testleri, kodunuzun bir kısmının nerede olduğunu vurgulayacaktır. Michael C. Feathers'ın Legacy Code ile Etkili Bir Şekilde Çalışmasını okumanızı tavsiye ederim . Projeniz yeni olsa bile, zaten (veya çok fazla) birim testine sahip değilse, kodunuzu güzel bir şekilde test etmek için açık olmayan bazı tekniklere ihtiyacınız olabilir.

Kısaca:

Test edilebilir kod (genellikle) bakım kodudur - ya da test edilmesi zor olan kodun bakımı genellikle zordur . Test edilebilir olmayan kod tasarlama, tamir edilemeyen bir makine tasarlamaya benzer - sonunda tamir etmesi için atanacak zavallı mırıldanmaya acıyın (o da siz olabilirsiniz).

Bir örnek, bir kimlik doğrulama yöntemi tipi döndürecek bir fabrika yaratmayı planlıyoruz. Asla olacağı somut türden başka bir şey olacağını tahmin etmediğimizden, bir arayüzü miras almasına gerek yok.

Üç yıl içinde beş farklı kimlik doğrulama yöntemi türüne ihtiyacınız olacağını biliyorsunuz, şimdi söylediniz, değil mi? Gereksinimler değişir ve tasarımınızı değiştirmekten kaçınmanız gerekirken, test edilebilir bir tasarıma sahip olmak, tasarımınızın (sadece) acı çekmeden değiştirilebilecek yeterli dikişlere sahip olduğu anlamına gelir; değişikliklerin hiçbir şeyi bozmaz.

Bağımlılık enjeksiyonunu tasarlamak kod kokusu değildir - en iyi yöntemdir. DI kullanımı sadece test edilebilirlik için değildir. Bileşenlerinizi DI etrafında inşa etmek modülerlik ve yeniden kullanılabilirlik sağlar, ana bileşenlerin (örneğin bir veritabanı arayüz katmanı gibi) değiştirilmesine daha kolay olanak sağlar. Bir dereceye kadar karmaşıklık eklerken, doğru yapılması, katmanların daha iyi ayrılmasını ve karmaşıklığın yönetilmesini ve gezinmesini kolaylaştıran işlevsellik izolasyonunun ayrılmasını sağlar. Bu, her bir bileşenin davranışını doğru bir şekilde doğrulamayı kolaylaştırır, hataları azaltır ve ayrıca hataları izlemeyi kolaylaştırır.

Bu, temel olarak DI'yi kabul etmek için Web API denetleyici sınıfını tasarladığımız anlamına gelir (yapıcısı veya ayarlayıcısı aracılığıyla); denetleyiciyi bu şekilde tasarlamak zorunda kalmamak için Ninject gibi üçüncü taraf bir çerçeve, ancak yine de bir arayüz oluşturmak zorunda kalacağız.

Bir test edilebilir arasındaki farka bakalım:

public class MyController : Controller
{
    private readonly IMyDependency _thing;

    public MyController(IMyDependency thing)
    {
        _thing = thing;
    }
}

ve test edilemeyen kontrolör:

public class MyController : Controller
{
}

Eski seçenek, ikisi de Visual Studio tarafından otomatik olarak oluşturulabilen 5 ekstra kod satırı içeriyor. Bağımlılık enjeksiyon çerçevenizi IMyDependencyçalışma zamanında somut bir türle değiştirecek şekilde ayarladıktan sonra - herhangi bir iyi DI çerçevesi için, başka bir tek kod satırı olan - Just Just Works ile ilgili her şey, şimdi kontrol cihazınızı kalbinizin içeriğine göre alay edebilir ve test edebilirsiniz. .

Test edilebilirliğe izin vermek için 6 ekstra kod satırı ... ve meslektaşlarınız bunun "çok fazla iş" olduğunu mu savunuyorlar? Bu tartışma benimle uçmuyor ve seninle uçmamalı.

Ve yok oluşturmak ve test için bir arabirim uygulamak zorunda: Moq , örneğin, birim test amaçlı beton türünün davranışını simüle etmek için izin verir. Tabii ki, bu tipleri test ettiğiniz sınıflara enjekte edemezseniz, bu size pek faydası olmaz.

Bağımlılık enjeksiyonu, bir kez anladığınızda, "bu olmadan nasıl çalıştım?" Diye merak ettiğiniz şeylerden biri. Çok basit, etkili ve sadece Mantıklı. Lütfen, meslektaşlarınızın projenizi test edilebilir kılma yolunda yeni şeyler anlamadaki eksikliklerine izin vermeyin.

Birim testleri yazarken, kodumda neyin yanlış gidebileceğini düşünmeye başladım. Kod tasarımını geliştirmeme ve tek sorumluluk ilkesini (SRP) uygulamama yardımcı oluyor . Ayrıca, birkaç ay sonra aynı kodu değiştirmeye geldiğimde, mevcut işlevselliğin bozulmadığını doğrulamama yardımcı oluyor.

Saf işlevleri kullanabildiğiniz kadar kullanma eğilimi vardır (sunucusuz uygulamalar). Birim testi durumu izole etmeme ve saf fonksiyonlar yazmama yardımcı oluyor.

Özellikle, çok ince olacak bir Web API servisimiz olacak. Başlıca sorumluluğu, web isteklerini / yanıtlarını toplamak ve iş mantığını içeren temel bir API'yi aramak olacaktır.

Önce ilgili API için birim testleri yazın ve yeterli geliştirme süreniz varsa, ince Web API hizmeti için de testler yazmanız gerekir.

TL; DR, birim testi kod kalitesini yükseltmeye ve gelecekteki kod riskinde değişiklik yapmanıza yardımcı olur. Aynı zamanda kodun okunabilirliğini de arttırır. Amacınızı belirtmek için yorumlar yerine testleri kullanın.

Sonuç olarak ve isteksiz partiyle argümanınız ne olmalı, hiçbir çelişki olmaması. Büyük hata, birinin testten nefret eden insanlara "test için tasarım yapma" fikrini oluşturduğu görülüyor. Ağızlarını kapatmalı ya da "bunu doğru yapmak için zaman ayıralım" gibi farklı bir şekilde söylemeliydiler.

Test edilebilir bir şey yapmak için "bir arayüz uygulamanız gerekir" fikri yanlış. Arabirim zaten uygulandı, henüz sınıf bildirgesinde ilan edilmedi. Mevcut kamu yöntemlerini tanımak, imzalarını bir arayüze kopyalamak ve bu arayüzü sınıfın beyanında ilan etmek meselesidir. Programlama yok, mevcut mantıkta değişiklik yok.

Görünüşe göre bazı insanlar bu konuda farklı bir fikir var. Öncelikle bunu düzeltmeyi denemenizi öneririm.