요즘 채용공고에 흔히 볼 수 있는 프로젝트의 테스트 자동화 경험이란 무엇일까?
실제 '스프링부트와 AWS로 혼자 구현하는 웹 서비스' 책에서 말하길 모 서비스 회사의 경우 코딩 테스트를 알고리즘이 아닌 프로젝트를 만들고, 단위 테스트를 필수조건으로 두었다고한다.
그만큼 테스트 코드는 빠질 수 없는 요소인 것 같다.
이번 프로젝트를 진행 할 때, 테스트 코드를 작성할 것 같은데, 테스트 코드에 대해 조금 찾아 보았다. 먼저 TDD와 단위 테스트는 다른 의미이다.
TDD vs Unit Test
TDD는 테스트가 주도하는 개발을 이야기하고, 테스트코드를 먼저 작성하는 것 부터 시작.
반면, 단위 테스트(Unit Test)는 TDD의 첫 번째 단계인 기능 단위의 테스트 코드를 작성하는 것을 이야기 한다. TDD와 달리 테스트 코드를 꼭 먼저 장성해야 하는 것도 아니고, 리팩토링도 포함하지 않는다.
테스트 코드를 사용하는 이유?
일반적으로 단위 테스트를 배우기 전 진행하는 개발 방식은,
- 코드를 작성하고,
- 프로그램(Tomcat)을 실행한 뒤,
- Postman과 같은 API 테스트 도구로 HTTP 요청.
- 요청결과를 System.out.println()으로 눈으로 검증.
- 결과가 다르면 다시 프로그램(Tomcat)을 중지하고 코드를 수정.
여기서 2~5는 매 코드를 수정할 때 마다 반복해야함.
톰갯을 재시작하는 적지않은 시간 소요...
왜 계속 톰캣을 재시작 하는 일이 반복될까? 바로 테스트 코드가 없다 보니, 직접 눈으로 확인해야 하기 때문.
따라서 테스트 코드는
1) 프로그램(Tomcat)을 재시작 할 필요를 없애고,
2) 더이상 눈으로 검증 할 필요없이, 자동검증을 가능하게 하며
3) 개발자가 만든 코드를 안전하게 보호
- 3번에 대한 추가적인 설명
예를들어, B라는 기능이 추가되어 테스트할때, B 기능이 잘 되어 오픈했더니 기존에 잘되던 A 기능에 문제가 생긴 것을 발견. 이런 문제는 규모가 큰 서비스에는 빈번하게 일어남.
하나의 기능을 추가할 때마다 너무나 많은 자원이 들기 땨문에 서비스의 모든기능을 수정적으로 할 수 없습니다. 이렇게 새로운 기능이 추가될 때, 기존 기능이 잘 작동되는 것을 보장해주는 것이 테스트 코드이다.
Unit Test를 함으로써 얻는 이점.
- 단위 테스트는 계발 단계 초기에 문제를 발견하게 도와줌.
- 단위 테스트는 개발자가 나중에 코드를 리팩토링하거나 라이브러리 업그레이등에서 기존 기능이 올바르게 작동하는지 확인할 수 있다. (ex, 회귀 테스트)
- 단위 테스트는 기능ㅇ에 대한 불확실성을 감소시킨다.
- 단위 테스트는 시스템에 대한 실제 문서를 제공한다. 즉, 단위 테스트 자체가 문서로 사용될 수 있다.
테스트 코드 프레임워크
1) JUnit - Java
2) DBUnit - DB
3) CppUnit - C++
4) NUnit - .net
출처 : '스프링부트와 AWS로 혼자 구현하는 웹 서비스' 책
