알려진 결함에 대한 단위 테스트를 받아야합니까?

내 코드에 알려진 결함이 포함되어 있지만 아직 수정되지 않았으며 현재 릴리스에서 수정되지 않고 향후에 수정되지 않을 수 있습니다. 해당 버그에 대한 단위 테스트에 실패한 경우 테스트 스위트? 단위 테스트를 추가하면 (분명히) 실패하고 실패한 테스트에 익숙해지는 것은 나쁜 생각처럼 보입니다. 반면에, 알려진 결함이고 알려진 실패 사례가있는 경우, 어느 시점에서 수정되어야하고 이미 테스트를 사용할 수 있으므로 테스트 스위트에서 제외시키는 것이 이상해 보입니다.

대답은 '예'입니다. 작성하고 실행해야합니다.

테스트 프레임 워크에는 "알려진 실패한 테스트"범주가 필요하며 이러한 테스트는 해당 범주에 속하는 것으로 표시해야합니다. 이를 수행하는 방법은 프레임 워크에 따라 다릅니다.

흥미롭게도, 갑작스럽게 통과하는 실패한 테스트는 예기치 않게 실패하는 통과 테스트만큼이나 흥미로울 수 있습니다.

나는 당신이 현재 행동으로 주석을 테스트하고 의견에 올바른 테스트와 올바른 행동을 추가해야한다고 생각합니다. 예:

@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));
}

이 방법으로 수정 프로그램을 사용할 수 있으면 빌드에 실패하고 실패한 테스트를 알 수 있습니다. 테스트를 살펴보면 동작을 변경했으며 테스트를 업데이트해야한다는 것을 알게됩니다.

편집 : 캡틴 맨 (Captain Man) 대변인이 말했듯이, 큰 프로젝트에서 이것은 곧 수정되지 않지만 문서화를 위해 원래의 대답은 아무것도 아닌 것보다 낫습니다.

더 좋은 방법은 현재 테스트를 복제하여 복제본이 올바른 것을 주장하고 @Ignore메시지와 함께 메시지를 작성하는 것입니다.

@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));
}

이것은 @Ignored 테스트 횟수를 줄이기 위해 팀의 규칙과 함께 제공됩니다 . OP가 버그 픽스가 현재 릴리스에 포함되지 않는다고 OP와 같이 팀에 중요한 경우 빌드에 실패하지 않는 한 버그를 반영하기 위해 테스트를 도입하거나 변경하는 것과 동일한 방법 .

테스트 툴에 따라 omit또는 pend기능을 사용할 수 있습니다 .

루비의 예 :

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

이 omit명령은 테스트를 건너 뛰고 테스트와 omit_if결합합니다-내 예제에서는 버전 번호를 테스트하고 오류가 해결 될 것으로 예상되는 버전에 대해서만 테스트를 실행합니다.

내 예제의 출력은 다음과 같습니다

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

내 대답 : 예, 테스트를 구현하십시오. 그러나 테스터를 오류와 혼동하지 마십시오.

버그가 마음에 새기고 지금 단위 테스트를 작성할 시간이 있다면 지금 작성하여 알려진 실패로 플래그 지정하여 빌드 자체에 실패하지 않도록하십시오. 버그 트래커는 현재이 버그에 대해 실패한 단위 테스트가 있음을 반영하여 업데이트되어 결국 수정하도록 지정된 사람이 다시 작성하지 않도록해야합니다. 이것은 버그가있는 코드가 많은 리팩토링을 필요로하지 않고 API가 크게 변경된다고 가정합니다.이 경우 테스트 작성 방법에 대한 더 나은 아이디어가 나올 때까지 단위 테스트를 작성하지 않는 것이 좋습니다 .

대답은 NO IMHO입니다. 버그에 대한 수정 작업을 시작할 때까지 그리고 버그를 증명하는 테스트를 작성하는 것보다 버그 보고서에 따라 테스트가 실패 할 때 버그에 대한 단위 테스트를 추가해서는 안됩니다 ( s) 테스트를 통과하기 위해 실제 코드를 수정하고 버그를 해결하고 그 후에 다룰 것입니다.

내 세상에는 버그가 수정 될 때까지 QE가 실패한 수동 테스트 사례가 있습니다. 그리고 개발자로서 우리는 수동 실패 TC와 버그 추적기를 통해 그것을 알고있을 것입니다.

실패한 UT를 추가하지 않는 이유는 간단합니다. UT는 개발자로서 현재 작업중인 것에 대한 직접적인 피드백 및 검증을위한 것입니다. 그리고 UT는 CI 시스템에서 사용되어 해당 모듈의 다른 코드 영역에서 의도하지 않은 부분이 발생하지 않도록합니다. 알려진 버그 IMHO에 대해 UT가 의도적으로 실패하는 것은 생산적이지 못하고 명백한 잘못 일 것입니다.

나는 대답이 실제로 있다고 가정합니다. 그것에 대해 실용적입니다. 글을 쓰면 무엇을 얻을 수 있습니까? 어쩌면 그것은 당신의 마음에 신선합니까?

버그를 수정할 때 버그를 노출시키는 단위 테스트를 작성하여 버그가 존재 함을 증명하는 것이 좋습니다. 그런 다음 버그를 수정하면 단위 테스트를 통과해야합니다.

실패한 단위 테스트를 지금 작성할 시간이 있습니까? 작성 / 수정해야 할 더 많은 압박 기능이나 버그가 있습니까?

당신이 로그인 버그와 관할 버그 추적 소프트웨어가 가정하면, 실패한 단위 테스트를 작성하지 않아도 정말이없는 지금은 .

버그 수정없이 릴리스가 시작되기 전에 실패한 단위 테스트를 도입하면 혼란이 발생할 수 있습니다.

시간이 지남에 따라 목록이 너무 커지거나 동일한 테스트에서 관련이없는 실패가 "예상 된"것으로 무시되기 때문에 테스트 스위트에서 알려진 실패에 대해 보통 불안합니다. 똑같은 일이 간헐적으로 실패하는 경우도 있습니다. 코드에 대한 테스트를 지금 작성하는 것에 투표하고, 일단 수정되었지만 주석 처리되거나 비활성화 된 코드 여야합니다.