테스트 주도 개발 - 3부 29장

29장 xUnit 패턴

 

단언(assertion)

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

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

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

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

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

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

 

픽스처

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

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

 

외부 픽스처

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

 

테스트 메서드

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

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

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

 

예외 테스트

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

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

 

전체 테스트

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