Bilinen kusurlar için birim testleri yapmalı mıyım?

Kodum, düzeltilmesi gereken ancak henüz geçmemiş olması ve mevcut sürüm için düzeltilmemesi gereken ve öngörülebilir gelecekte düzeltilmemesi gereken bilinen bir kusur içeriyorsa, bu hata için başarısız bir ünite testi yapılmalıysa, test odası? Birim testini eklersem, (açıkçası) başarısız olur ve başarısız testlere alışmak kötü bir fikir gibi görünüyor. Öte yandan, bilinen bir kusur ise ve bilinen bir başarısızlık durumu varsa, bir noktada sabitlenmesi gerektiği ve testin zaten hazır olması gerektiği için, onu test odasının dışında tutmanın garip olduğu görülmektedir.

Cevap evet, onları yazmalı ve çalıştırmalısınız.

Test çerçeveniz "bilinen başarısız testler" kategorisine ihtiyaç duyar ve bu testleri bu kategoriye giriyor olarak işaretlemelisiniz. Bunu nasıl yaptığınız çerçeveye bağlıdır.

Tuhaf bir şekilde, aniden geçen bir başarısızlık testi beklenmedik bir şekilde başarısız olan bir başarısızlık testi kadar ilginç olabilir.

Bence şu anki davranışla ilgili bir birim testiniz olmalı ve yorumlarda doğru testi ve doğru davranışı eklemelisiniz. Örnek:

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

Bu yolla, düzeltme kullanılabilir olduğunda, yapı başarısız olur ve başarısız sınava girer. Teste baktığınızda, davranışı değiştirdiğinizi ve testin güncellenmesi gerektiğini bileceksiniz.

EDIT: Kaptan Adam'ın dediği gibi, büyük projelerde, bu yakın zamanda herhangi bir zamanda çözülmeyecek, ancak dokümantasyon uğruna orijinal cevap hiç yoktan iyidir.

Bunu yapmanın daha iyi bir yolu, mevcut testi kopyalamak, klonu doğru olanı iddia etmesini sağlamak ve @Ignoreörneğin bir mesajla

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

Bu, @Ignored testi sayısını azaltmak için ekibinizdeki kongre ile birlikte gelir . Aynı hatayı yansıtmak için testin tanıtılması veya değiştirilmesiyle yaptığınız gibi, takımınız için kritik öneme sahipse derlemede başarısız olmamanız dışında, OP'nin bu düzeltmenin mevcut sürüme dahil edilmeyeceğini söylediği gibi .

Test aracına bağlı olarak bir omitveya pendişlevi kullanabilirsiniz .

Ruby'de örnek:

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

omitKomut bir test atlar, omit_ifbir test ile birleştirir it - Ben sürüm numarasını test etmek ve yalnızca hata çözüldü bekliyoruz sürümleri için testi yürütmek benim örnekte.

Örneğimin çıktısı:

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

Yani cevabım: Evet, testi uygulayın. Ancak bir test cihazının, arızalanacağını bildiğiniz hatalarla karıştırmayın.

Eğer aklınızdaki böcek taze ve birim testini şimdi yazmak için vaktiniz varsa, o zaman şimdi yazacağım ve bilinen bir hata olarak işaretleyeceğim, böylece derlemenin kendisi başarısız olmayacaktı. Hata izleyiciniz, bu hata için şu anda başarısız olan bir ünite testi olduğunu yansıtacak şekilde güncellenmelidir, böylece sonunda onu düzeltmek için atanan kişi, onu tekrar yazmaz. Bu, buggy kodunun çok fazla yeniden denetlemeye gerek duymadığını ve API'nin önemli ölçüde değiştiğini varsayalım - eğer öyleyse, testin nasıl yazılması gerektiği hakkında daha iyi bir fikir edinene kadar ünite testini yazmamanız daha iyi olabilir. .

Cevap NO IMHO. Hata düzeltmesi üzerinde çalışmaya başlamadan önce ve hatayı ispatlayan test (ler) i yazmadan ve bu test (ler) hata raporuna uygun olarak başarısız olduğunda, hata için bir birim testi eklememelisiniz. s) testleri geçmesi için gerçek kodu girip düzelteceksiniz ve hata çözülecek ve bundan sonra ele alınacaktır.

Benim dünyamda, QE'lerin hata giderilinceye kadar başarısız olduklarını gösteren manuel bir test durumu olacaktı. Ve biz geliştiriciler olarak biz TC manuel hata ile ve böcek izci ile farkında olacaktır.

Başarısız UT'leri eklememenin nedeni basittir. UT'ler, şu anda geliştirici olarak çalıştığım şeyin doğrudan geri bildirimi ve doğrulaması içindir. Üstelik UT'ler CI sisteminde o modülün diğer bazı kod alanlarında istemeden bir şey kırmadığımdan emin olmak için kullanılır. UTS'nin bilerek bir hatayı bilerek başarısızlığa uğraması, IMHO'ya karşı üretken ve sadece yanlış olacaktır.

Sanırım cevabı gerçekten, buna bağlı. Pragmatik olun. Şimdi yazmak size ne kazandırıyor? Belki aklında tazedir?

Hatayı düzeltirken, hatayı açığa vuran bir birim testi yazarak var olduğunu ispatlamak mükemmel bir anlam ifade eder. Daha sonra hatayı düzelttiniz ve birim testi geçmelidir.

Şu anda başarısız ünite testini yazmak için vaktin var mı? Yazılması / düzeltilmesi gereken daha fazla özellik ya da hata var mı?

Yetkili hata takip yazılımına sahip olduğunuzu varsayarak, giriş yapmış bir hata varsa, şu anda başarısız olan ünite testini yazmaya gerçekten gerek yoktur .

Muhtemelen bir hata düzeltme olmadan gerçekleşmekte olan bir sürümden önce başarısız bir ünite testi uygularsanız bazı karışıklıklar ortaya çıkarabilirsiniz.

Genellikle test süitlerinde bilinen başarısızlıkları hissetmekten rahatsız oluyorum çünkü listenin zaman içinde büyümesi ya da aynı testlerdeki ilgisiz başarısızlıklar "beklendiği gibi" reddedilmesi çok kolay. Aynı şeyler aralıklı arızalar için de geçerlidir - kodu gizleyen kötü bir şey olabilir. Testi şu anda olduğu gibi yazmak için oy kullandım ve bir kez olması gerektiği gibi düzeltildi, ancak yorumlandı veya bir şekilde devre dışı bırakıldı.