11. 단위 테스트의 실제
10장에서 나열한 테스트의 특징을 나타낼 가능성을 극대화하기 위해 적용할 수 있는 실제적인 방법이 많이 있다.
1. 기능뿐만 아니라 동작을 시험하라
함수당 하나의 테스트만 있는 것은 적절하지 않을 때가 많다.
코드가 제대로 테스트되는지 여부를 측정하기 위한 한 가지 좋은 방법은 수정된 코드에 버그나 오류가 있음에도 여전히 테스트를 통과할 수 있는지에 대해 생각해보는 것이다.
테스트 대상의 코드의 각 줄, if 문, 논리 표현식, 값 등은 그것이 존재하는 이유가 있어야 한다. 불필요한 코드라면 제거 되어야 함.
코드가 나타내는 중요한 동작이 있는 경우 그 동작을 테스트하는 테스트 케이스가 있어야 하므로, 기능을 변경한 경우 적어도 하나의 테스트 케이스가 실패해야 한다.
2. 테스트만을 위해 퍼블릭으로 만들지 말라
프라이빗 함수는 구현 세부 사항이며 클래스 외부의 코드가 인지하거나 직접 사용하는 것이 아니다. 때로는 이러한 프라이빗 함수 중 일부를 테스트 코드에서도 접근하려고 할 수 있다. 하지만 이건 좋은 생각이 아니다. 구현 세부 사항과 밀접하게 연관된 테스트가 될 수 있고 궁극적으로 우리가 신경써야 하는 코드의 동작을 테스트하지 않을 수 있다.
프라이빗 함수를 퍼블릭으로 만든 후에 테스트할 때 문제는 다음과 같다.
- 이 테스트는 실제로 우리가 신경 쓰는 행동이 아니다. (프라이빗 함수를 테스트한다고 하더라도 이를 사용하는 퍼블릭에서 오용할 수 있음)
- 테스트가 구현 세부 사항에 독립적이지 못하게 된다. 프라이빗 함수가 있다는 사실은 구현 세부 사항이다.
- 프라이빗 함수를 변경한 것이 퍼블릭 api를 변경한 효과를 갖는다.
- ‘테스트를 위해서만 공개’와 같은 주석문은 간과되기 쉽기 때문에 다른 개발자가 해당 프라이빗 함수를 사용해서 이 기능에 의존할 수 있다. 이후에는 함수를 수정하기 어려워진다.
해결책) 퍼블릭 api를 통해 테스트하라
해결책2) 코드를 더 작은 단위로 분할하라
3. 한 번에 하나의 동작만 테스트하라
여러 동작을 한꺼번에 테스트하면 테스트가 제대로 안될 수 있다.
테스트가 이해하기 어렵고 통과하지 못한 경우 이유를 잘 설명하지 않으면, 다른 개발자의 시간을 낭비할 뿐만 아니라 버그가 발생할 가능성도 커진다.
모든 것을 한꺼번에 테스트하는 테스트 케이스는 정확히 무엇이 변경됐는지 알려주는 대신, 무언가 변경됐다는 것만 알려준다. 따라서 코드를 의도적으로 변경할 때 그 변경으로 인해 어떤 동작이 영향을 받았고 어떤 동작이 영향을 받지 않았는지 정확히 알기 어렵다.
해결책) 각 동작은 자체 테스크 테이스에서 테스트하라
훨씬 더 나은 접근법은 잘 명명된 테스트 케이스를 사용하여 각 동작을 개별적으로 테스트하는 것이다.
각 테스트 케이스 이름에서 어떤 동작을 테스트하고 있는지 정확하게 식별할 수 있으며, 테스트의 작동 방식을 이해하기 위해 코드를 파악하는 것이 비교적 쉽다.
4. 공유 설정을 적절하게 사용하라
beforeAll, beforeEach 등의 테스트 유틸
5. 적절한 어서션 확인자를 사용하라
js의 경우 jasmin등
6. 테스트 용이성을 위해 의존성 주입을 사용하라
하드 코딩된 의존성은 테스트를 불가능하게 할 수 있다.