TDD kullanılırken bir işlev veya özellik nasıl kaldırılır

TDD hakkındaki metinlerde sık sık yeniden düzenleme adımı sırasında "çoğaltmayı kaldır" veya "okunabilirliği geliştir" hakkında okudum. Ama kullanılmayan bir işlevi kaldırmamı sağlayan nedir?

Örneğin en sınıfı olduğunu varsayalım Cyöntemlerle a()ve b(). Şimdi bir yönteme f()sahip olmanın iyi olacağını düşünüyorum C. Aslında, f()tüm çağrıları b(), tanımlanan / tanımlanan ünite testleri dışında değiştirir b(). Artık gerekli değildir - testler hariç.

Sadece kaldırmak b()ve onu kullanan tüm testleri kaydetmek mi? "Okunabilirliği artır" ın bir parçası mı?

Evet tabi ki. Okunması en kolay kod, orada olmayan koddur.

Bununla birlikte, yeniden düzenleme genellikle kodu davranışını değiştirmeden geliştirmek anlamına gelir. Kodu geliştiren bir şey düşünüyorsanız, sadece yapın. Yapmanıza izin verilmeden önce bir güvercin deliğine sığdırmanıza gerek yok.

Genel bir yöntemi kaldırmak "yeniden düzenleme" değildir - yeniden düzenleme, mevcut testleri geçmeye devam ederken uygulamayı değiştirir.

Ancak, gereksiz bir yöntemi kaldırmak son derece makul bir tasarım değişikliğidir.

TDD bunu bir dereceye kadar çıkarır, çünkü testleri incelerken, gereksiz bir yöntemi test ettiğini gözlemleyebilirsiniz. Testler tasarımınızı yönlendiriyor, çünkü "Bakın, bu testin hedefimle hiçbir ilgisi yok".

Kod kapsamı araçlarıyla birlikte daha yüksek test seviyelerinde kendini daha iyi gösterebilir. Kod kapsamı ile tümleştirme sınamaları yürütürseniz ve yöntemlerin çağrılmadığını görürseniz, bir yöntemin kullanılmadığına dair bir ipucu. Statik kod analizi, yöntemlerin kullanılmadığını da gösterebilir.

Bir yöntemi kaldırmak için iki yaklaşım vardır; her ikisi de farklı koşullarda çalışır:

1. Yöntemi silin. Herhangi bir bağımlı kodu ve testleri silmek için derleme hatalarını izleyin. Etkilenen testlerin tek kullanımlık olduğundan memnunsanız değişikliklerinizi yapın. Değilse, geri alın.

2. Eski olduğunu düşündüğünüz testleri silin. Tüm test paketinizi kod kapsamıyla çalıştırın. Test takımı tarafından kullanılmayan yöntemleri silin.

(Bu, test takımınızın başlangıç ​​için iyi kapsama alanına sahip olduğunu varsayar).

Aslında f (), b () 'yi tanımlayan / tanımlayan birim testleri hariç tüm b () çağrılarını değiştirir

IMHO tipik TDD döngüsü şöyle görünecektir:

• f () için başarısız testler yaz (muhtemelen b () testlerine dayanır): testler kırmızı olur

• uygulamak f () -> testler yeşil olur

• refactor : -> b () ve b () için tüm testleri kaldır

Son adım için, önce b () 'yi kaldırmayı ve ne olacağını görmeyi düşünebilirsiniz (derlenmiş bir dil kullanırken, derleyici sadece mevcut testlerden şikayet etmelidir, eğer değilse, b için eski birim testleri başarısız olur, bu yüzden bunları da kaldırmanız gerektiği açıktır).

Evet öyle.

En iyi, en hatasız, en okunabilir kod, mevcut olmayan koddur. Gereksinimlerinizi yerine getirirken mümkün olduğunca kodsuz yazmaya çalışın.

b()Artık kullanılmadığında çıkarılması arzu edilir , aynı nedenden dolayı kullanılmayan fonksiyonların ilk etapta eklenmemesi arzu edilir. İster "okunabilirlik" ya da başka bir şey olarak adlandırın, diğer her şey eşittir, kodun hiçbir faydası olmadığı bir kod geliştirmesidir. Sahip olmamanın daha iyi olduğu en az bir özel önlem olması uğruna, bu değişiklikten sonra gelecekteki bakım maliyetinin sıfır olduğunu garanti eder!

b()Yeni bir şeyle değiştirmenin herhangi bir düşüncesi elbette şu anda çağıran tüm kodların göz önünde bulundurulması b()ve testlerin tüm kodların bir alt kümesi olması nedeniyle testleriyle gerçekten kaldırmak için gereken herhangi bir özel teknik bulamadım . ".

Genellikle benim için çalıştığını akıl yürütme çizgisi noktasında ben fark nerede olduğunu f()kaydetmiştir b()nedenle eskimiş b()en azından kullanım dışı olmalı ve ben tüm aramaları bulmak için arıyorum b()çağrıları ile bunların yerine niyetiyle f(), I test kodunu da dikkate alın . Özellikle, b()artık gerekli değilse , birim testlerini kaldırabilirim ve kaldırmalıyım.

Sen hiçbir şey oldukça haklısınız güçler haber beni o b()artık gereklidir. Bu bir beceri meselesidir (ve ince söylediği gibi, üst düzey testlerle ilgili kod kapsamı raporları). Sadece birim testler ve fonksiyonel testler b()söz konusu değilse, o zaman dikkatli bir şekilde yayınlanan herhangi bir arayüzün bir parçası olmadığından iyimser olabilirim ve bu yüzden kaldırmak doğrudan kontrolüm altında olmayan herhangi bir kod için bir kırılma değişikliği değildir.

Kırmızı / yeşil / refactor döngüsü testlerin kaldırılmasından açıkça bahsetmez. Dahası, kaldırma b()açıkça bileşeni beri açık / kapalı ilkesine aykırı olduğu değişiklik için açık. Bu adımı basit TDD'nin dışında bir şey olarak düşünmek istiyorsanız, devam edin. Örneğin, bir testin "kötü" olduğunu bildirmek için bir işleminiz olabilir; bu durumda, orada olmaması gereken bir şeyi (gereksiz işlev b()) test ettiği gerekçesiyle testi kaldırmak için uygulanabilir .

Uygulamada çoğu insanın muhtemelen kırmızı / yeşil / refactor döngüsüyle birlikte belirli bir miktarda yeniden tasarım yapılmasına izin verdiğini veya kesin olarak konuşsa bile yedek ünite testlerinin "refactor" un geçerli bir parçası olduğunu düşünüyorlar. yeniden düzenleme değil. Ekibiniz, bu kararı doğrulamak için ne kadar drama ve evrakın dahil edilmesi gerektiğine karar verebilir.

Her neyse, b()önemli olsaydı, bunun için fonksiyonel testler olurdu ve bunlar hafifçe kaldırılmazdı, ancak zaten sadece birim testler olduğunu söylemiştiniz. Birim testleri (kodun değiştirdiğiniz mevcut iç tasarımına yazılır) ve fonksiyonel testler (belki de değiştirmek istemediğiniz yayınlanmış arayüzlere yazılır) arasında doğru bir şekilde ayrım yapmazsanız, daha dikkatli olmanız gerekir birim testlerini kaldırma hakkında.

Her zaman hatırlamaya çalışmamız gereken bir şey, şimdi SÜRÜM KONTROLÜ ile KOD YATAKLARI kullanıyoruz. Silinen kod aslında gitmedi ... hala önceki bir yinelemede bir yerlerde. Öyleyse uçur! Delete tuşu ile liberal olun, çünkü her zaman geri dönebilir ve bir gün yararlı olabileceğini düşündüğünüz değerli zarif yöntemi alabilirsiniz ... eğer bir gün gelirse. Orada.

Tabii ki, bu, hastalığın uyarısı ve geriye dönük uyumlu olmayan sürümlerin tehlikesi ile birlikte gider ... arayüz uygulamanıza dayanan, şimdi (aniden) kullanımdan kaldırılan kodunuzla yetim kalan harici uygulamalar.