본문 바로가기
SW

테스트 주도 개발(Test-Driven Development:By Example) - 3부 : 테스트 주도 개발의 패턴 (29장)

by 라꾸스떼(YR) 2020. 2. 17.
반응형

[29장] xUnit 패턴

<단언(assertion)>

불리언(boolean) 수식을 작성해서 여러분 대신 프로그램이 자동으로 코드가 동작하는지에 대한 판단을 수행하도록 하라.

테스트를 완전히 자동화하려면 결과를 평가하는 데 개입되는 인간의 판단을 모조리 끄집어내야 한다. 버튼을 누르면 컴퓨터가 실행하는 코드의 작동이 올바른지 검증하는 데 필요한 모든 판단이 되어야 하는 것이다.

-판단 결과가 불리언 값이어야 한다. 일반적으로 참 값은 모든 테스트가 통과했음을 의미하고, 거짓 값은 뭔가 예상치 못했던 일이 발생했음을 의미한다.

-이 불리언 값은 컴퓨터에 의해 검증되어야 한다.

단언은 구체적이어야 한다.

코드가 제대로 작동하는지를 판다낳기 위한 용도로 변수를 사용하길 원한다면 언제나 설계를 향상할 수 있는 기회가 있다. 하지만 두려움 때문에 포기하고 그냥 변수를 사용하기로 결정해 버리면 이 기회를 잃게 된다.

 

<픽스처>

객체들을 세팅하는 코드는 여러 테스트에 걸쳐 동일한 경우가 있다. (이러한 객체들은 테스트 픽스처(fixture)). 이와 같은 중복은 다음과 같은 이유로 좋지 않다.

-인터페이스를 수동으로 변경할 필요가 있을 경우, 여러 테스트를 고쳐주어야 한다.

 

<외부 픽스처>

각 테스트의 목적 중 하나는 테스트가 실행되기 전과 실행된 후의 외부 세계가 동일하게 유지되도록 만드는 것임을 기억하기 바란다.

 

<테스트 메서드>

동일한 픽스처를 공유하는 모든 테스트는 동일한 클래스의 메서드로 작성될 것이다. 다른 종류의 픽스처를 필요로 하는 테스트는 다른 클래스에 존재하게 된다.

관습에 의해 메서드 이름은 ‘test’로 시작한다. 툴은 이 패턴을 자동으로 인식하고 주어진 클래스에 대한 테스트 슈트를 생성한다.

테스트 메서드는 의미가 그대로 드러나는 코드로, 읽기 쉬워야 한다.

 

<예외 테스트>

예상되는 예외를 잡아서 무시하고, 예외가 발생하지 않은 경우에 한해서 테스트가 실패하게 만들면 된다.

우리가 원하는 정확한 종류의 예외만을 잡아내야 한다는 점에 유의하기 바란다.

 

<전체 테스트>

모든 테스트 슈트에 대한 모음을 작성하면 된다.(각각의 패키지에 대해 하나씩, 그리고 전체 애플리케이션의 패키지 테스트를 모아주는 테스트 슈트)

반응형

댓글