# Overview 요즘 채용 공고들을 보면 테스트 코드 작성 경험이 있는지 TDD 경험이 있는지를 요구하는 경우가 엄청 많아졌다. 그러나 나는 빨리 개발해서 납품해야하는 SI 개발을 주로 해온 입장에서 테스트 코드를 작성해본 경험이 거의 없다시피 하다. ~~(빡빡한 일정 내에 요구사항 개발하기 바빠 죽겠는데 테스트 코드를 언제 짜고 있나;;)>~~ 프로젝트 기간 중 테스트 한다라고 해봤자 단위테스트에서 내 손으로 한 기능 한 기능씩 눌러보고 문서를 작성하거나, 통합테스트를 한다고해도 시나리오를 작성해서 그 시나리오대로 정상 작동하는지를 확인해본게 전부다. ~~(진짜 주먹구구 그 자체였군..)~~ 그래서 사람들이 그토록 찾는 TDD(Test-Driven Development)가 대체 뭔지? 테스트 종류는 뭐가 있는지 개념을 알아보고자 한다.

# TDD(Test-Driven Development)가 뭐지? TDD는 우리 말로 풀어쓰면 `테스트 주도 개발 방법론(Test-Driven Development, TDD)`이다. 간단하게 말하면 개발하면서 테스트 코드 작성을 위주로 개발하겠다라는 얘기다. 단, 개발을 위한 코드를 먼저 작성하고 테스트 코드를 작성하는게 아니라 **테스트 코드를 먼저 작성하고 그 테스트 코드 기반으로 개발하겠다**이다.
## 프로세스 TDD를 채택하고 개발할 때 절차는 다음과 같고, 아래 절차를 개발이 완료될 때까지 무한 반복한다.
1. 개발하려는 기능에 대한 테스트 케이스를 작성하고 테스트를 실행한다. 단, 처음에는 기능 개발이 아무것도 된게 없기때문에 반드시 실패해야한다. 2. 1번에서 작성한 테스트 케이스를 통과하기 위한 기능 개발 코드를 작성하고 테스트를 실행한다. 3. 2번에서 테스트를 통과했으면 코드를 리팩토링하고 테스트를 실행한다. 이 때 추가적인 테스트 케이스가 작성될 수 있다.
## 장점 * 코드 품질이 우수해진다. 테스트를 그렇게 돌려대는데 안좋은게 이상할거같긴하다. * 유지보수가 쉬워진다. 명확하게 개발해야할 기능이 있을 때 그 기능에 대한 테스트 케이스가 이미 모두 있을테니 코드 리팩토링도 쉬워진다.
## 단점 * 개발 생산성이 저하된다. 테스트 코드를 먼저 작성하면서 개발해야 하기 때문에 개발 속도가 느려질 수밖에 없다. * 그냥 어렵다. 테스트 코드를 작성하는데도 생각할게 많고 테스트 코드를 작성하기 위한 설계도 필요하다.
## 솔직한 내 생각 SI에 종사하고 있다면 그냥 안하는게 낫다고 생각된다. 납기가 중요한 SI 특성상 테스트 코드까지 작성할 여력이 없다. ~~(애초에 개발 기간을 충분히 주는 곳을 본적이 없다.)~~ 익숙해지면 그냥 개발하는거랑 거의 차이 안난다라고 여러 말은 들었는데 솔직히 그 말에 공감이 가진 않는다. 비즈니스 로직이 복잡한 코드를 작성해야할 때 과연 그렇게 순탄하게 될까? 테스트 코드 작성하는데 하루종일 걸리고 그 테스트를 통과하기 위한 개발 코드도 하루종일 짜고 있을거 같다. 공공기관이나 대학교 행정시스템을 겪어본 나로서는 솔직히 의문이다. DB에 저장되있는 무슨 코드 값이 뭐일 때는 이렇게 돌아가고, 또 뭐일 때는 저렇게 돌아가야되고, 또 뭐일 때는 또 다른 로직이 돌아가야되고 하는 경우를 많이 봤는데 이런 경우는 그냥 TDD 적용 안하는게 정신 건강에 이로울거 같다. 솔직히 테스트 코드도 사람이 작성하는 것일텐데 조삼모사에 가까울거 같다. 이거도 야메로 하면 그거대로 돌아는갈거 같은 느낌? 그래도 상시 유지보수 해야되는 제품이 있거나 플랫폼 개발을 한다면 괜찮을거 같다.

# 테스트 종류 * 테스트에도 크고 작은 레벨의 테스트를 위한 여러 테스트가 있다. 그 종류에 대해 알아보자
## 단위 테스트 (Unit Test) 가장 작은 단위의 모듈 또는 기능을 테스트하는 단계이다. 즉, 의존성을 가지는 다른 기능과 연계해서 테스트하는게 아니라 단 하나의 기능 단위만을 보고 독립적으로 동작이 잘 되는지를 테스트하는 것이다. 쿠팡을 예로 들었을 때 장바구니에 상품이 잘 담겼는지, 장바구니에 담은 상품이 구매가 되는지를 각각 테스트하는 것이라 볼 수 있다.
## 통합 테스트 (Integration Test) 가장 작은 단위의 모듈 또는 기능을 통합해서 기능끼리 연계되는 여러 단위를 검증하기 위해 테스트하는 단계이다. 즉, 각각의 비즈니스 로직이 올바르게 동작하기 위한 기능들의 묶음을 시나리오화해서 정상 동작되는지를 테스트하는 것이다. 쿠팡을 예로 들었을 때 사용자가 장바구니에 상품이 담고, 상품을 구매한다라는 시나리오대로 연계해서 제대로 동작하는지 테스트하는 것이라 볼 수 있다.
## e2e 테스트 (End-To-End Test) 애플리케이션의 처음부터 끝까지에 대한 전체 흐름을 테스트하는 단계이다. 즉, 통합 테스트가 단위 테스트의 묶음이듯이 e2e 테스트는 통합 테스트의 묶음이다. 각 비즈니스 로직이 연계되어 시스템 그 자체가 정상 동작되는지를 테스트하는 것이다. 쿠팡을 예로 들었을 때 사용자가 사이트에 접속해서 로그인하고 상품을 검색해서 보고 선택한 상품을 장바구니에 담아서 구매까지 잘되는지 시스템의 전반적인 흐름이 매끄럽게 정상 동작하는지 확인하는 단계라 볼 수 있다.

# Reference * [https://f-lab.kr/insight/understanding-and-practicing-tdd](https://f-lab.kr/insight/understanding-and-practicing-tdd) * [https://inpa.tistory.com/entry/QA-%F0%9F%93%9A-TDD-%EB%B0%A9%EB%B2%95%EB%A1%A0-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C](https://inpa.tistory.com/entry/QA-%F0%9F%93%9A-TDD-%EB%B0%A9%EB%B2%95%EB%A1%A0-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C) * [https://soojae.tistory.com/74](https://soojae.tistory.com/74) * [https://fe-developers.kakaoent.com/2023/230209-e2e/](https://fe-developers.kakaoent.com/2023/230209-e2e/)

댓글