테스트를 적을 때 고려해야 할 점

coverage 가 높다고 다가 아니다.

테스트를 적을 때 고려해야 할 점

구현하기 전에 궁금한 건 다 적어 본다

테스트가 완수 조건이 될 수 있도록 구현하기 전에 궁금한 건 다 적어 본다. 기획서에 있는 사항들도 테스트에 다 넣어보자.

given, when, than으로 명확하게 기술한다

명확하지 않은 테스트는 향후 테스트 의도를 알 수 없게 된다. 잘 읽히도록 기술하자

테스트 모듈당 System Under Test는 보통 하나다

테스트 모듈에서 sut 가 여러 개면, 뭔가 이상한 거다. sut 가 두 개 이상이어야 하는지 다시 생각해보자.

테스트하는 관점에 따라 명확하게 테스트해야 한다

현재 레이어의 관심사에 맞게 테스트를 해야 한다. 아래 레벨일수록 촘촘하게, 윗 레벨에서는 각 구현체들이 정확히 위빙 되는지 테스트를 하는 게 맞다

구현에 의존된 테스트를 할게 아니면 interface를 모킹 해서 테스트해보자

아래 layer에서 이미 테스트를 다 했던 건데, 굳이 한번 더 테스트할 이유가 없다

테스트하기 힘들거나 이상하면, 테스트하는 모듈이 명확하지 않은지 다시 생각해본다

내가 만드는 게 테스트 조차 힘들면, 이상한 거다.

테스트 커버리지가 정책적으로 무결함을 보장하진 않는다

커버리지를 통과했다고 정책적으로 완벽함을 보장하진 않는다. 애매한 케이스는 테스트로 표현하고 제대로 테스트하자.

테스트는 다시 봐야 한다 (테스트도 리펙토링의 대상이다)

중복도 제거해야 하고, 좀 더 의도가 명확하게 드러나야 할 필요가 있을 수도 있다. 테스트는 계속 리팩터링 해야 하는 부분이다.

귀찮다고 복붙 하지 말자

귀찮다고 복붙 하지 말자. 제발.

계속 추가해 보자