좋은 단위 테스트 판별법 (FIRST)
이전 포스팅까지 우리는 단위 테스트가 많은 장점을 갖는다는 것을 배웠다.
그렇다면 무조건 적기만 하면 좋은 것일까?
단위 테스트도 하나의 코드이기 때문에 좋은 테스트와 그렇지 못한 테스트로 나눌 수 있다.
개발자들이 보편적으로 "좋은 단위 테스트" 라고 부르는 테스트는 FIRST 규칙을 따른다고 한다.
좋은 코드를 작성하기 위한 지침서 Clean Code 에서 이 FIRST 규칙에 대해 설명하고 있어 해당 내용을 정리해보겠다.
- Fast
- Independent
- Repeatable
- Self-Validating
- Timely
Fast
좋은 단위 테스트는 실행이 빨라야한다.
단위 테스트는 내부 코드만 테스트할 때와 외부 자원을 다룰 경우의 실행 시간 차이가 크다.
모든 외부 자원을 다루어 한 테스트가 200ms를 소모할 때 2500개의 테스트를 수행한다면 8분이 걸리게 된다.
단위 테스트는 대상 시스템에 대해 지속적이고 빠르게 피드백을 주는데 가치가 있기 때문에 빨라야 한다.
단위 테스트의 실행이 오래 걸린다면 테스트 작성의 의미가 퇴색되는 것이므로 우리는 느린 테스트 코드를 지양해야 한다.
Isolated
좋은 단위 테스트는 테스트하고자 하는 단위 기능에 집중해야 한다.
단위 테스트를 작성할 때 테스트하고자 하는 단위 기능을 명확하게 하지 않는다면 그 테스트는 하나 이상의 기능을 테스트 할 것이다.
단위 테스트가 통합 테스트보다 장점을 갖는 것은 하나의 테스트 당 하나의 기능만을 테스트하기 때문이다.
Repeatable
좋은 단위 테스트는 반복적으로 수행하더라도 항상 같은 결과를 반환해야 한다.
그렇기 위해서는 결과가 어떻게 나올지 명확해야 하며 통제할 수 있어야 한다.
테스트 대상 코드의 나머지를 격리하고 Mock객체를 활용하는 방안을 사용해 이를 해결할 수 있다.
Self-validating
좋은 단위 테스트는 기대하는 결과가 무엇인지 단언(assert)해야 한다.
테스트 결과를 검증할 때 System.out.println이나 log.info등을 이용해 직접 비교하며 검증할 수도 있다.
하지만 이렇게 되면 많은 비용을 지불하게 된다.
그렇기 때문에 JUnit에서 제공하는 assert와 같은 검증 코드를 이용해 검증하도록 한다.
Timely
좋은 단위 테스트는 미루지 않고 즉시 작성한다.
단위 테스트는 소프트웨어 개발의 완성도, 품질을 높이는 좋은 습관이다.
만약 테스트를 제때 작성하지 않고 미루어 작성하지 않는다면 코드에 결함이 발생할 확률이 높아진다.
이런 점에서 TDD와 같은 프로세스가 등장하게 되었다.
Reference
