유일한 논리가 가드 인 단위 테스트 방법에 유용합니까?

다음과 같은 방법이 있다고 가정 해보십시오.

public void OrderNewWidget(Widget widget)
{
   if ((widget.PartNumber > 0) && (widget.PartAvailable))
   {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

내 코드에 여러 가지 메소드가 있습니다 (비동기 웹 서비스 호출의 앞쪽 절반).

단위 테스트로 다루는 것이 유용한 지 토론 중입니다. 그렇습니다 여기에는 논리가 있지만 그것은 단지 보호 논리입니다. (웹 서비스 호출이 발생하기 전에 필요한 것들이 있는지 확인합니다.)

저의 일부는 "일단 테스트 할 수는 있지만 시간이 가치가 없다"고 말합니다 (이미 일정이 미진한 프로젝트에 있습니다).

그러나 저의 다른 쪽은, 당신이 그들을 단위 테스트하지 않으면 누군가가 경비원을 변경하면 문제가있을 수 있다고 말합니다.

그러나 내 첫 번째 부분은 누군가가 경비원을 변경하면 경비원을 더 많이 만들고 있다고 말합니다 (지금은 경비원을 변경하고 경비원의 단위 테스트를 수행해야하기 때문입니다).

예를 들어 서비스에서 위젯 가용성을 확인해야 할 책임이있는 경우 더 이상 경비를 원치 않을 수 있습니다. 그것이 단위 테스트를 받고 있다면 지금 두 곳을 바꿔야합니다.

나는 두 가지 방법으로 장단점을 봅니다. 그래서 다른 사람들이 한 일을 물어볼 것이라고 생각했습니다.

저의 일부는 "일단 테스트 할 수는 있지만 시간이 가치가 없다"고 말합니다 (이미 일정이 미진한 프로젝트에 있습니다).

세 가지 매우 짧은 테스트입니다. 당신은 자신에게 질문을하는 데 많은 시간을 보냈습니다.

그러나 저의 다른 쪽은, 당신이 그들을 단위 테스트하지 않으면 누군가가 경비원을 변경하면 문제가있을 수 있다고 말합니다.

이쪽을 들으십시오.

그러나 내 첫 번째 부분은 누군가가 경비원을 변경하면 경비원을 더 많이 만들고 있다고 말합니다 (지금은 경비원을 변경하고 경비원의 단위 테스트를 수행해야하기 때문입니다).

관리자가 TDD 너트 인 경우 더 어렵습니다. 관련 변경이나 테스트 추가없이 내가 변경하면 열심히 생각해야합니다. 실제로, 나는 계속 진행하기 전에 테스트를 추가하고 변경하기를 원할 것입니다.

당신의 첫 부분은 명백한 잘못입니다. 두 번째 부분에 등을 두드리고 그것에 대해 생각하지 마십시오.

가드 로직과 실제 순서가 별도의 방법이라면 단위 테스트를 단순화합니다.

에서 Widget클래스

public bool IsReadyForOrdering { get { return PartNumber > 0 && PartAvailable; } }

또는 다른 곳의 동등한 방법

public bool IsWidgetReadyForOrdering(Widget widget)
{
    return widget.PartNumber > 0 && widget.PartAvailable;
}

주문 방법

public void OrderNewWidget(Widget widget)
{
   if (IsWidgetReadyForOrdering(widget)) {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

이제 테스트 IsWidgetReadyForOrdering가 쉬워졌습니다. 더 이상 그것에 대해 오래 생각하지 마십시오. 그것을 테스트하십시오!

단위 테스트 일정에 시간이 없지만 확실한 QA 사용을위한 시간을 따로 떼어 놓은 경우 해당 QA 시간 중 일부를 도용하여 단위 테스트를 작성할 수 있는지 또는 일부 QA 기간을 보낼 수 있는지 묻습니다 단위 테스트를 수행하거나 비 단위 테스트 코드를 처리 할 수 ​​있습니다. 불행히도 일정이 양보를하거나 강제로 사망하도록 강요하는 일정은 일반적으로 첫 번째 옵션을 제안합니다. 해당 기간 동안 시스템을 올바르게 유지 관리합니다.

즉, 가드 진술을 테스트하는 일반적인 질문에; 예! 가드 진술을 절대적으로 테스트하십시오! 사람들은 그 방법, 당신은 버그 수정을하는 사람의 오해 뭔가를 찾으려하고 가드를 제거하거나 변경하지 않을의 행동의 중요한 부분입니다 &&가 ||당신 것? 단위 테스트는 a) 당신이 실제로 경비원의 논리를 올바르게 얻었는지, 그리고 b) 어떤 이유로 인해 단위 테스트를 실행할 때 불만을 제기하지 않고 나중에 그 논리를 위반하지 않는지 확인합니다.

위의 훌륭한 답변이 있으며, 그 요점은 매우 중요합니다. 그러나 놓친 것 같은 것은 포괄적 인 단위 테스트 세트를 가지고 있다는 것입니다. 코드의 매우 상세한 사양처럼 읽습니다. 코드가 너무 간단하여 테스트 유효성 검사를 생략하면 어떻게 잘못 될 수 있는지 알기가 어렵고 사양의 일부가 빠져 있습니다. 이러한 테스트를 놓친 팀에 들어간 경우 실제로 서비스가 해당 인수의 유효성을 검증하지 않은 것으로 가정합니다.

코드는 코드입니다. 테스트 할 때 100 % 적용 범위를 확보해야합니다. 중요하지 않은 경우에는 없을 것입니다.