숙련주차 강의 중 Jest 테스팅 프레임워크를 이용하여
3-Way Layered Architecture Pattern 을 한 계층씩 테스팅을 해보았다.
그러다 생긴 궁금증을 몇개 적어보았다.
그리고 튜터님께 대답을 들은 것과 검색하며 알게된 것을 적어보겠다.
현업에서는 어떤 방식? 순서?로 테스팅을 하는가?
회사 by 회사, 팀 by 팀, 프로젝트 by 프로젝트! 다 다르다.
튜터님은 기능을 구현하고 Service 계층을 테스팅 한다고 하셨다.
기본적으로 Service 계층에 비지니스 로직이 대부분 구현되어 있고
함수를 테스팅하면 하위 계층인 Repository 계층까지 테스팅 하는 것이 되므로, 각각의 모든 계층을 테스트 하는 것은
같은 것을 중복적으로 테스팅 하는 것일 수도 있다고 하셨다.
TDD (Test Driven Develpoment - 테스트 주도 개발) VS 기능 구현 완료 후 테스트
이 문제도 회사나 팀 마다 다 다르다.
솔직히 구글링 조금만 해봐도 'TDD가 중요하다!', 'TDD 방법론이 중요한 이유!' 라면서 온갖 블로그 글이 작성되어 있다.
TDD 는 작은 단위의 테스트 케이스를 작성해 가며 통과하는 코드를 작성해 기능을 반복적으로 구현해 나가는 방법이다.
일반적인 개발은 기능을 구현 완료 후 테스팅 과정을 거친다.
TDD 는 작성한 코드의 불안전성을 낮춰서 생산성을 높일 수 있다는 장점이 있고, 개발자의 손을 떠나기 전에 피드백을 진행할 수 있다.
하지만, 초기의 실패하는 테스트 케이스의 작성법이 난이도가 있는 것 같고, 테스트 작업과 기능 구현 작업을 왔다갔다 하며 진행해야 하므로 과정이 복잡해 보일 수 있다.
시간적인 문제도 있을 수 있다. 테스트 케이스를 만들어가며 기능을 구현하면 안전성은 높이지만 오래 걸릴 수 있다.
이러한 특징들 때문에 각자 선호하는 방법론이 다 다르다.
TDD를 한다면 어떤 계층부터 구현을 하는 것이 좋을까?
이 문제도 사람 by 사람이다.
하지만, Controller 계층은 Service 계층을 부르고, Service 계층은 Repository 계층을 부르기 때문에
Repository 계층 부터 테스팅하며 개발하는 것이 조금 더 수월하지않을까? 한다.
잘 봐써요@,!