Kod incelemesi, birim testlerinden önce veya sonra yapılmalıdır

Kod incelemesinin ne zaman yapılacağı konusunda meslektaşımla - birim testlerinden önce veya sonra tartışıyorum. En iyi uygulama nedir?

Dikkate almamız gereken bazı faktörler (daha fazlası olabilir):

• Kod değişikliğinin boyutu - büyük bir değişiklik, kod incelemesinden daha fazla değişiklik olacağı anlamına gelir. Bu değişiklikler daha büyükse, UT kod incelemesinden önce geldiyse, UT'lerinizin çoğunu tekrarlamanız gerekir.
• Birim testi yapmak için gereken süre
• Yeni bir işlev mi yoksa bir hata düzeltmesi mi

Kod incelemesini yapmadan önce daima birim testi yapmalısınız ve işte neden

1. Kodunuz birim testleri tarafından yakalanacak bir şekilde kırılırsa, diğer geliştiricinin zamanını kırmızı / yeşil / refactor döngüsüne dahil ederek harcarsınız.
2. Testler, diğer geliştiricilere kodun amaçlanan kullanımını göstererek incelemeyi kolaylaştırır.
3. Test durumlarını kaçırmanız veya testlerinizin düzgün çalışmaması durumunda testler, test edilen kodla birlikte gözden geçirilmelidir.
4. Testler ve kod incelemesi, bulunan sorunlarda çok az çakışma ile farklı sorunları yakalama eğilimindedir. Birim testleri, inceleme yapan kişi sorunları bulduğunda kodu yeniden test etmek zorunda kalmaz, geliştiriciler rahatsız olur ve muhtemelen ikinci kez de yapmazlar.

Muhtemelen başka nedenler de vardır, ancak bunlar 3 farklı ekip / şirket içinde kod inceleme uygulamaları uygularken şahsen gördüğüm ve yaşadıklarım.

Düzenle Elbette yukarıdaki kod inceleme yazılım geliştirme sürecinde (şelale veya çevik olsun) bir adım olduğu zamanlar içindir. Özellikle büyük veya zor bir kod bölümü üzerinde çalışıyorsanız, herhangi bir noktada başka bir çift göz almaktan çekinmeyin.

Kod İncelemeleri, kod "tamamlandığında" içindir.

Kuruluşumda "tamamlandı" tanımımız birim testleri (TDD'yi hedeflediğimiz gibi) içerir, böylece kod incelemeleri tam koddur - ve tam kod testleri içerir.

Ayrıca, testlerin gözden geçirilmesi ve yeniden düzenlenmesi gerekir, böylece kod incelemesinin bir parçası oldukları anlaşılır.

Testler gözden geçirilecek kodun bir parçası olarak düşünülmelidir. Bu nedenle testler yapıldıktan sonra gözden geçirmek mantıklıdır.

Testlerin de gözden geçirildiğinden emin olun. Bu, birim testlerde yeni olanlar için önemlidir.

Ekibinizin bağımlılık enjeksiyonunu, izolasyon çerçevelerini, saplamaları ve saplamaları, dikişleri, devlete dayalı testlerle etkileşimi ve birim testlerine entegrasyonu aldığından emin olun.

Yukarıda belirtilen konuları uygulamanız gerekmez, ancak bunları anlamanız gerekir.

İyi,

Bu, "Birim Testi" ile ne demek istediğinize bağlıdır ...

TDD stili Birim Testi olsaydı, kodunuzu yazarken test yazdığınız için anlamsızdır. Sonradan bir durum yok.Bu durumda kod kalitesini sürekli olarak artırıyorsunuz: Yeniden düzenleme ...

VE

Klasik "birim testi" olsaydı [bilmediğim anlamına gelir, ama kodları yazdıktan ve genellikle diğer çocuklar tarafından yapıldıktan sonra test demek istiyorum] o zaman ana kriter kodlama ve birim testlerin doğasından beklediğiniz şeydir: eğer hızlı geri bildirim yapmak ve işlem yapmak ve otomatik birim testi yapmak istemiyorsanız, birim testini beklemek zorunda kalacaksınız. Kod incelemesi ile olgun sorunları tanımlamak ve sonraki iterasyonlar için aşamalı olarak çözüm uygulamak istiyorsanız, bunu birim testinden önce yapabilirsiniz ...

Ama sonuçta kişisel olarak, kod incelemesi için, sonra veya daha sonra birim test benim için gerçek bir kriter değil ...

Neden kod incelemesi yapıyoruz? Kod kalitesi için ... "Kalite kontrol" kapısı yerine, yazılım geliştirme süreci ortamınıza kalite enjekte edin ...

Ben söyleyebilirim, "çevik" olalım ... bazı hızlı, gayri resmi kod incelemesi yapmak için kodun bitmesini beklemeyin: gerçekten kiminle ve tüm konular için bekleyebilirsiniz geliştiriciler vardır kod + test aşaması tamamlanacak ... ama

gerçekten yeni konulara gelince (tamamen yeni özellik, araştırmaya yakın, takıma tamamen yeni bir şey), kod gözden geçirme erken, zaman kaybetmeyin: bir iş arkadaşınızın zaman zaman bir göz atmasını sağlayın: izolasyon önemli bir faktördür bu durumda başarısızlık.

geliştirici ekip için yeniyse, kodu erken ve belki de sık sık gözden geçirin .

ve bu arada, birim testlerinin de kod incelemesine ihtiyacı vardır.