Amacı anlamadığım kod için testler yazmak

Geçenlerde bir kara kutu yeniden düzenlemesini tamamladım. Kontrol edemiyorum, çünkü nasıl test edileceğini çözemiyorum.

Yüksek düzeyde, başlangıçları bazı B sınıfından kapma değerleri içeren bir sınıfa sahibim. B sınıfı "boş" ise, bazı makul varsayılanlar oluşturur. Bu bölümü, B sınıfını aynı varsayılanlara ayarlayan bir yönteme çıkardım.

Her iki sınıfın amacını / içeriğini veya nasıl kullanılacağını henüz çözemedim. Bu yüzden nesneyi boş bir B sınıfından başlatamıyorum ve doğru değerlere sahip olduğunu kontrol ediyorum / doğru şeyi yapıyor.

En iyi fikrim orjinal kodu çalıştırmak, ilklendirilen üyelere bağlı olarak genel metotların sonuçlarında kod yazmak ve yeni kodu buna karşı test etmek. Bu fikirden neden bu kadar rahatsız hissettiğimi tam olarak ifade edemiyorum.

Burada daha iyi bir saldırı var mı?

testing refactoring

— JETM
kaynak

Yanlış taraftan başladığını hissediyorum. Önce kodu anlamalısın, sonra test et, sonra refactor. Neden kodun ne olduğunu bilmeden neden yeniden yönlendiriyorsun?

— Jacob Raihle

@JocobRaihle Asla dokunmadığım şeylerde derece olan insanlar için oldukça uzmanlaşmış bir program. Gittiğimde bağlamı tespit ediyorum, ancak başlamadan önce sağlam bir anlayışa sahip olmak için beklemek pratik değil.

— JETM

Pratik olmayan şey, şeyleri yeniden yazmak ve değişiklikler üretimdeyken neden olmaması gerektiğini keşfetmektir. Daha önce iyice test edebilecekseniz , sorun değil, bu kod tabanını tanımanın iyi bir yolu olabilir. Değilse, değiştirmeden önce anlamanız zorunludur .

— Jacob Raihle

Sistemin gerçek davranışını test etmek istediğinizde için Karakterizasyon testi adlı özel bir test türü vardır . Sadece orijinal sisteminizi alırsınız, daha sonra gerçekte ne yaptığını söyleyen testler eklersiniz (ve mutlaka yapılması gerekenin ne olduğunu değil!). Davranışını koruduğundan emin olarak, güvenle değiştirebileceğiniz sisteminiz etrafında bir iskele görevi görür.

— Vincent Savard

Eğer soramaz / birileri tarafından incelenme yapar bunu anlamak?

— pjc50

Yanıtlar:

122

İyi yapiyorsun!

Otomatik regresyon testleri oluşturmak çoğu zaman bir parçayı yenilenebilir hale getirmek için yapabileceğiniz en iyi şeydir. Şaşırtıcı olabilir, ancak bu tür testler genellikle, giriş ve çıkış "arayüzlerini" (o kelimenin genel anlamında) anladığınız sürece, bileşenin dahili olarak ne yaptığını tam olarak anlamadan yazılabilir. Geçmişte bunu sadece dersler için değil, tam gelişmiş miras uygulamaları için birkaç kez yaptık ve çoğu zaman tam olarak anlamadığımız şeyleri engellememize yardımcı oldu.

Bununla birlikte, yeterli test verisine sahip olmanız ve yazılımın o bileşenin kullanıcısı açısından ne yaptığını anladığınızdan emin bir şekilde emin olmanız gerekir, aksi takdirde önemli test durumları çıkarırsınız.

Yeniden test etmeye başlamadan önce otomatik testlerinizi uygulamak iyi bir fikirdir , sonrasında değil, yeniden düzenleme işlemini küçük adımlarla yapabilir ve her adımı doğrulayabilirsiniz. Yenileme işleminin kendisi kodu daha okunaklı hale getirmelidir, bu yüzden iç kısımlar hakkındaki bilginizi azar azar artırmanıza yardımcı olur. Yani bu süreçte sipariş adımları

"dışarıdan" kodunu anlamak,
regresyon testleri yazar,
refactor, kodun içindekilerin daha iyi anlaşılmasını sağlar

— Doktor Brown
kaynak

Aynı zamanda, "Eski

— Kodla

Bir zamanlar böyle bir şey yapmak zorunda kaldım. Değiştirmeden önce uygulamadan tipik çıktı verilerini topla, daha sonra aynı test verilerini çalıştırarak uygulamanın yeni sürümünü kontrol et. 30 yıl önce ... Fortran ... Bir tür görüntü işleme / haritalama şeyiydi, bu yüzden 'bakarak' çıktının ne olduğunu veya test senaryoları yazarak ne olması gerektiğini gerçekten bilemedim. Ve bunu Tektronix vektörü (kalıcı) bir ekranda yaptım. Hükümet işi ... 2 Teletypes arkamda beceriyor.

Biri ekleyebilirsiniz, gerçekte sonra hala eski kod için testlerinizi yazabilirsiniz. Daha sonra bunları yeniden yapılandırılmış sürümünüzde deneyebilirsiniz ve eğer kırılırsa, kırılma başlayacağı noktayı bulmak için taahhüt geçmişinizde bir saptama araştırması yapın.

— CodeMonkey

Bir şey daha yapmayı öneriyorum. Test verilerini toplarken, mümkünse kod kapsama istatistiklerini toplayın. Test verilerinizin söz konusu kodu ne kadar iyi tanımladığını bileceksiniz.

— liori

@nocomprende, Geçen haftayı eski bir bilimsel fortran 77 koduyla kesin olarak yaptım. Ascii verilerinin bir dosyaya yazdırılması eklenir, girdiler ve beklenen çıktı ile birlikte test dizinleri oluşturulur ve test durumum iki çıktı kümesinden sadece bir farklılıktı. Karakter için karakterle uyuşmazlarsa, bir şey kırdım. Kod çoğunlukla her biri 2-3k LoC olan iki alt program olduğunda, bir yerden başlamanız gerekir.

— Godric Seer

Ünite testleri yazmak için önemli bir neden, bileşen API'sini bir şekilde belgelemeleridir. Test edilen kodun amacını anlamamak burada gerçekten bir sorundur. Kod kapsamı, hangi yürütme dallarının var olduğunu ve nasıl tetiklendiklerini bilmeden elde edilmesi zor olan bir diğer önemli hedeftir.

Bununla birlikte, durumu temiz bir şekilde sıfırlamak (veya her seferinde yeni test nesnesini oluşturmak) mümkün ise, sisteme çoğunlukla rastgele girdi besleyen ve çıktıyı gözlemleyen bir "çöp kutusu içi çöp" tipi testler yazılabilir.

Bu tür testlerin sürdürülmesi zordur, çünkü başarısız olduklarında, neden ve ne kadar ciddi olduğunu söylemek karmaşık olabilir. Kapsam sorgulanabilir olabilir. Ancak hala hiç olmamasından çok daha iyi. Bu tür bir test başarısız olduğunda, geliştirici en son değişiklikleri daha dikkatli bir şekilde revize edebilir ve umarım hatayı burada tespit edebilir.

— h22
kaynak

Her türlü bilgi kör uçuştan iyidir. Hata ayıklayıcısını bir çökme dökümü dosyasına (Unix) çağırarak ve yığın izlemesini sorarak, üretimde olan sunucu programlarındaki hataları bulmak için kullanılır. Bana hatanın oluştuğu işlevin adını verdi. Başka hiçbir bilgim olmasa bile (bu hata ayıklayıcısını nasıl kullanacağımı bilmiyordum), aksi halde gizemli ve yeniden üretilemez bir durumun ne olacağı konusunda yardımcı oldu.