예, 항상 고립 된 것은 아닙니다

정교하게 해주세요 :

단위 테스트 란 무엇입니까?

에서 레거시 코드를 효과적으로 작업을 ¹ :

단위 테스트라는 용어는 소프트웨어 개발에서 오랜 역사를 가지고 있습니다. 단위 테스트의 대부분의 개념에 공통되는 것은 소프트웨어의 개별 구성 요소를 분리 한 테스트라는 개념입니다. 구성 요소 란 무엇입니까? 정의는 다양하지만 단위 테스트에서는 일반적으로 시스템의 가장 원자적인 동작 단위에 관심이 있습니다. 절차 코드에서 단위는 종종 기능입니다. 객체 지향 코드에서 단위는 클래스입니다.

getter와 setter를 찾는 OOP를 사용하면 단위는 클래스 이며 반드시 개별 메소드는 아닙니다. 입니다.

좋은 시험은 무엇입니까?

모든 요구 사항 및 테스트는 Hoare 로직 의 형식을 따릅니다 .

{P} C {Q}

어디:

• {P}전제 조건입니다 ( 주어진 )
• C트리거 조건입니다 ( when )
• {Q}사후 조건이다 ( then )

그런 다음 최대가됩니다.

구현이 아닌 테스트 동작

즉 C, 사후 조건을 달성하는 방법을 테스트하지 말고 {Q}그 결과인지 확인해야합니다 C.

OOP에 관해서 C는 클래스입니다. 따라서 내부 효과는 테스트하지 말고 외부 효과 만 테스트해야합니다.

왜 빈 게터와 세터를 따로 테스트하지 않는가?

게터와 세터는 약간의 로직을 포함 할 수 있지만, 너무 오래이 논리는 외부 효과가 없습니다 – 그들을 만드는 콩 접근 ⁽²⁾ 자를 ) 테스트는 객체 내부를 살펴 봐야합니다.

따라서 빈 getter와 setter를 분리해서 테스트해서는 안됩니다. 이것은 나쁘다 :

Describe 'LineItem class'

    Describe 'setVAT()'

        it 'should store the VAT rate'

            lineItem = new LineItem()
            lineItem.setVAT( 0.5 )
            expect( lineItem.vat ).toBe( 0.5 )

경우 만 setVAT예외를 슬로우 해주기 때문에, 해당 테스트는 적절한 것 이 외부 효과.

게터와 세터를 어떻게 테스트해야합니까?

이러한 효과가 나중에 영향을 주더라도 외부에 영향을 미치지 않으면 객체의 내부 상태를 변경하는 지점은 거의 없습니다.

따라서 세터와 게터에 대한 테스트는 내부 메소드가 아닌 이러한 메소드의 외부 효과에 대해 고려해야합니다.

예를 들면 다음과 같습니다.

Describe 'LineItem class'

    Describe 'getGross()'

        it 'should return the net time the VAT'

            lineItem = new LineItem()
            lineItem.setNet( 100 )
            lineItem.setVAT( 0.5 )
            expect( lineItem.getGross() ).toBe( 150 )

당신은 자신에게 생각할 수 있습니다 :

잠깐만, 우리는 getGross()여기서 테스트 하지 않습니다 setVAT() .

그러나 setVAT()오작동 인 경우 해당 테스트는 모두 동일하게 실패합니다.

_{¹ Feathers, M., 2004. 레거시 코드로 효과적으로 작업합니다. 프렌 티스 홀 프로페셔널.}

_{² Martin, RC, 2009. 깨끗한 코드 : 민첩한 소프트웨어 장인의 핸드북. 피어슨 교육.}

답변