단위 테스트 vs 통합 테스트 전략 이해

학습 키워드

Unit Test / Integration Test / E2E Test
테스트 Pyramid
테스트 커버리지 vs 유의미한 테스트

유닛테스트라는건 뭘까?
서비스단에서? 컨트롤단에서? 음 아무래도 상관없으려나
유닛테스트는 단위테스트라고 하며
그림을 보면 알수 있듯이 단위 테스트는 테스트 피라미드 바닥에 존재하며 굉장히 많은 수 가 있다는 것을 알 수 있습니다.
이는 간단하게 작성이 되어진다는 뜻이 되어집니다.

이전 포스트에서도 말했었지만 테스트코드는 굉장히 중요합니다. 그렇다는 이야기는 e2e를 하든 통합을 하든 유닛을 하든
작성을 하는것이 좋습니다. 여기서 중요한 사실은 유닛테스트가 양이 제일 많다는 것입니다. 그렇다는건 유닛테스트를 중점으로 테스트코드를 짜야 된다는 뜻이 됩니다.

그리고 그림에서 보면 알 수 있듯이 유닛테스트는 화이트 박스 테스트라고 한다. 그러니까 결과를 이미 아는 상태에서 진행이 된다는 것이다.

다시 생각해보면 TDD는 구현보다 테스트를 먼저 작성을 해야하기때문에 이미 결과값을 알아야 된다. 그럼 어찌보면 TDD개발론은 화이트박스로 해야 된다는 뜻이 된다.
그렇다는 이야기는 TDD는 단위 테스트로만 작성을 해야 하는 거라는 뜻이 된다.
위에 보면 알 수 있다시피 통합테스트와 e2e테스트 같은 경우는 블랙박스 테스트다 그렇다는건 결과를 아무도 짐작이 어렵다는 뜻이 된다.
그러면... TDD는 통합테스트나 e2e로는 불가한 걸까?

gpt한테 물어보니 꼭 불가능한건 아니라고 한다.
하지만 그 경우에도 정확한 spec이 존재하는 경우에는 TDD가 된다고 한다. 근데 정확한 spec... 음.. 이거 알면 블랙이 아니지 않나 다시 물어봐야겠다.
 물어보니까 꼭 그렇다는건 아니다. 어렵다...

암튼 그건 중요한건 아니구

통합테스트를 어떻게 작성을 할 수 있을까를 부터 고민을 해야 할거 같다.
통합테스트는 하나의 컴포넌트만 테스트하는것이 아닌 서비스 - 레파지토리를 함께 테스트 하는것을 말합니다.
그러면 결국 머리부터 발끝까지 전부 로직이 돌기때문에 테스트가 가능하다는것이 됩니다.
즉, 통합테스트는 말 그대로 통합적으로 특정 한 부분만 테스트 하는것이 아닌 전역에 걸처 테스트를 하는것을 뜻합니다.

다 쓴거 같다. 마지막으로
테스트 커버리지 vs 유의미한 테스트에 대해 말하면 될거 같다.
이거는 내 생각을 말하면 나는 테스트 커버리지는 의미가 없다고 생각한다.
일단 2가지 이유가 있는데 첫번째 이유는 테스트 커버리지를 100%가까이 작성한다고 한들 중복이 되는 부분들도 존재할 가능성이 높다고 생각한다. 두번째 이유는 성능이 떨어지기때문이다. 실제로 테스트커버리지는 성능에 영향을 미치는걸로 알고 있다.

그럼에도 불구 하고 테스트코드를 작성해야 하는 이유는 검증과정이다. 이 프로그램은 그래도 안정된 프로그램이라는 검증표라 생각한다.
결국, 테스트 커버리지보다는 유의미한 테스트를 짜려고 노력하는게 더 중요하다고 생각한다.
유의미한 테스트가 낮으면 얼마나 좋은가.. 

 

출처:
https://www.headspin.io/blog/the-testing-pyramid-simplified-for-one-and-all