Birim Test Yarışması

İşverenlerim aylık birim test günü yarışması düzenliyor. Tüm bir gün, birim testleri yazmaya adanmıştır - açıkçası ay boyunca daha fazla test yapıyoruz, ancak bu bütün bir gün - ve yarışmanın "kazananına" bir ödül verildi. Ancak kazananın kim olduğunu belirlemekte zorlanıyoruz.

Her test vakası için puan veriyoruz. Eğer böyle bir birim testi yazdıysanız ...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

size 100 puan verilecek. Açıkçası bu basit bir örnektir, ancak her test senaryosuna "puan" atama ile ilgili sorunları göstermektedir.

Biz öncelikle bir Java ve Javascript mağazasıyız. Bu yüzden metrik olarak test edilen kod dalı sayısını saymayı önerdim. Test edilen dalları bir kod kapsamı aracı (EclEmma gibi) ile kolayca sayabiliriz. Ancak, bunu Selenyum testlerimizle ve Javascript kaynaklarında kod kapsamı (herhangi bir fikir?) Almakla nasıl yapacağımızdan emin değilim.

Bu yarışmanın galibini nasıl daha iyi belirleyebileceğimiz konusunda herhangi bir öneriniz var mı?

Düzenle

Birim testleri yazmayı biliyorum, etkili birim testleri yazmayı biliyorum, neyi test edeceğimi belirlemek için yardıma ihtiyacım yok. Bu yarışma üzerinde hiçbir kontrolüm yok - yarışma devam edecek. Bu yüzden ya daha iyi hale getirmek için bazı girdiler ekliyorum ya da testleri oynamaya devam ediyorum (evet, onları oynuyorum. Tabii ki onları oynuyorum. Kazanacak ödüller var)

Düzenle

Bu soru burada , besbelli bir kopya değil iyi test durumları nasıl bulunacağı hakkında yararlı bilgiler içermektedir olsa da, rekabeti değerlendirmek için herhangi bir yararlı ölçümleri sağlamaz.

Bu yarışmanın galibini nasıl daha iyi belirleyebileceğimiz konusunda herhangi bir öneriniz var mı?

Bana mantıklı gelen tek şey oy kullanmaktır - her geliştirici diğer geliştiricilerin testine (kendi hariç) bazı puanlar verebilir. Belki test için 3 puan "en etkili" bir, ikincisi için 2 puan ve üçüncüsü için bir puan olduğunu düşünüyor. En çok puanı alan test kazanır. Nokta ataması, belirli bir testi kimin yazdığını önceden bilmeden daha iyi sonuçlar verebilir.

Bonus olarak, tüm testlerinizin akran değerlendirmesini alırsınız.

Eğer böyle bir birim testi yazdıysanız ...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

size 100 puan verilecek.

Bu kişiye 0 puan verirdim (test gerçekten alakalı bir şeyi test ediyor olsa bile), çünkü bir döngü içindeki iddialar çok az mantıklıdır ve birden fazla iddia ile testler (özellikle bir döngü veya harita şeklinde) ile çalışmak zordur.

Sorun aslında [kolayca] kandırılamayan bir metriğe sahip olmaktır. Yalnızca varsayım sayısına dayanan bir metrik, yazılı LOC başına ödeme yapan geliştiricilerle tamamen aynıdır. Büyük ve imkânsız bir kodun korunmasına yol açan LOC ile ödeme yönteminde olduğu gibi, gerçek şirket politikanız işe yaramaz ve muhtemelen kötü yazılmış testlere yol açar.

Varsayımların sayısı önemsiz ise, testlerin sayısı da önemsizdir. Bu, bu tür durumlar için hayal edebileceğiniz birçok metrikte (birleşik olanlar dahil) de geçerlidir.

İdeal olarak, sistemik bir yaklaşım uygularsınız. Uygulamada, bu durum çoğu yazılım geliştirme şirketinde pek işe yaramaz. Bu yüzden birkaç şey daha önerebilirim:

1. Testler için çift ​​incelemeleri kullanma ve dakika başına WTF sayısına benzer bir şeye sahip olma .

2. Bu testlerin zaman içindeki hata sayısı üzerindeki etkisini ölçün . Bunun birkaç faydası vardır:

   • Adil gözüküyor,
   • Hata raporları ve bunların kaderleri hakkında yeterli veri toplarsanız gerçekten ölçülebilir,
   • Aslında buna değer mi!

3. Şube kapsamını kullanın , ancak diğer metriklerle birleştirin (yanı sıra bir inceleme). Şube kapsamının faydaları vardır, ancak CRUD kodunu daha iyi bir not almak için test etmek, geliştiricilerin zamanını harcamak için en iyi yol değildir.

4. Şu an için uygulamak istediğiniz metriklerin ne olduğuna hep birlikte karar verin (bu tür kararlar hoş karşılanmayabilir veya hatta bazı şirket ve ekiplerde mümkün olmayabilir). Daha alakalı hale gelenleri seçerek metrikleri sık sık gözden geçirin ve değiştirin ve herkesin neyin nasıl ölçüldüğünü açıkça anladığından emin olun.

İşvereninizin, size hata bulma, daha fazla kod kapsamı elde etme ve ayrıca sonsuza dek yararlı olan daha fazla teste sahip olma teşvikleri vermek için bu birim test gününü organize ettiğini varsayalım.

Bu yüzden, kazananın en fazla hatayı bulan geliştirici veya testleri kod kapsamındaki en büyük artışı sağlayan geliştirici olması mantıklı olacaktır.

Bir test, sorun / hata / hata izleme sisteminizde yeni bir girişin açılmasına neden olursa puan kazanır. Bu sorun için bir giriş zaten açıksa, sayılmaz. Ayrıca, yorumlarda önerildiği gibi, kendi kodunuzdaki hatalar sayılmaz; yalnızca diğer kişilerin kodundaki hatalar sayılmalıdır. Ne yazık ki, bu yaklaşım anında tatmin olmuyor çünkü tüm başarısız testlerin elenmesi ve ilgili sorunların açılması birkaç gün sürebilir. Ayrıca, bu her zaman işe yaramayabilir; sisteminiz olgunlaştıkça, testler ekleyerek hataları bulmak son derece nadir hale gelebilir.

Kod kapsamındaki artış, yeni testlerin temsil ettiği iyileştirmenin daha objektif bir ölçümünü sağlayabilir. İlk olarak, toplam kod kapsamının yarışmadan bir gün önce kaydedilmesi gerekecektir. Daha sonra, her geliştiricinin, diğer geliştiriciler tarafından yazılan testlerden kaynaklanan kod kapsamındaki artışı hesaba katmadan, yalnızca testlerinden kaynaklanan kod kapsamındaki artışı bir şekilde göstermesi gerekecektir. Bu, muhtemelen herhangi bir test yapılmadan önce her geliştiricinin makinesine gidecek ve yeni kod kapsamını kaydedecek bir hakeme ihtiyacınız olacağı anlamına gelir.

Bu arada, kod kapsamını dikkate almak, soruda verdiğiniz örnek gibi aptalca şeyler yapmak yerine, gerçek testler yazan kişilere adil bir ödül sağlar.