개요

유닛 테스트 (단위 테스트)가 필요하다는 것은 다들 동의하고 이해하고 있다.

사실 개발 과정에 자연스레 녹여낸다면 더 할 나위 없겠지만, 그렇지 않은 경우의 팀도 꽤 많을 것이다.

나는 많은 좋은 팀들이 실천하고 있는 유닛 테스트를 개발 과정에 포함시키지 못하는 팀에서 시도 해볼만 한 유닛 테스트의 시점과 방법에 대해서 얘기해보고자 한다.

이미 유닛 테스트를 잘하는 팀이라도, 유닛 테스트 추가 시점은 참고 할 만 하지 않을까 싶기도 하다.

유닛 테스트 작성 시점

버그가 나오면, 그 버그를 수정하기 위한 테스트
- 재발 했을 때 감지될 테스트
테스트 추가 iteration 후의 효과
- 테스트 1주일 했다면, 대다수의 기본 기능에 대한 테스트셋이 나옴
- 이후 해당 다른 수정 시, 기존의 기능들이 깨지지 않는다는 것을 유닛 테스트로 감지 할 수 있게 됨

정상적인 상황
실패해야만 되는 상황
범위를 벗어난 입력
- 주로 변수의 타입을 가정하고, overflow, underflow를 중점적으로 확인하되, 가정한 임계치가 있다면, 그 임계치의 경계 값을 확인하면 더 좋다.
  유닛 테스트에서 확인해야 될 내용
호출 순서에 영향이 없는지
- 만약 있어야 한다면, 호출 순서가 뒤바뀌어도 문제가 없는지
범위가 넘어서는 값이 전달 될 때에도 잘 핸들링 하는지
함수 리턴 값 실패로 반환할 내용이 예외로 전달되고 있는지
외부 툴, 커스텀한 스크립트나 툴로 추가 진행해야 될 테스트 (유닛 테스트 범주 외)
성능이 중요한 경우 성능 테스트.
멀티스레딩 이슈 등이 있는 경우에는 반복 테스트
성능도 임계치에 근접할 때 자원이 (메모리, CPU) 잘 방어되고 있는지를 확인하는 테스트를 진행해야 한다.

테스트를 왜 하는가?

그 이유에 대해서 공감하지 못하거나, 어떤 효과를 원하는지에 대해서 합의나 이해가 없어서 비 효율적인 테스트, 혹은 효과적이지 못한 테스트, 있어서 나쁠건 없는 테스트 코드 들이 생산되고 이에 대한 코스트만 커지는 경우도 많이 보게 됐다.

그래서 내가 일해오면서 효과를 많이 본 테스트, 높지 않은 코스트로 가능한 테스트에 대해서 간략하게 정리해보았다.

유닛 테스트를 넘어선 스트레스 테스트, 부하 테스트에 대한 이야기는 추후 작성하도록 하겠다.