테스트 코드 도입을 위한 사전 조사

캐치캐치 프로젝트 1차적으로 배포 후 고도화를 위해 테스트 코드 도입을 위한 사전 조사

테스트 코드(TDD)를 작성하는 이유

• 예상치 못한 문제를 조기 처리 가능
• 작성한 코드가 의도한 대로 작동하는지 검증 가능
• 코드 변경에 대한 사이드 이펙트를 줄이는 예방책
• 코드 수정이 필요한 상황에서 유연하고 안정적인 대응이 가능
• 코드 변경 시, 변경 부분으로 인한 영향 쉽게 파악 가능
• 코드 리팩토링 시 기능이 동일하게 구현되었는 지에 대한 구별과 판단이 가능

테스트 코드의 종류

단위테스트 (unit)

• 코드에서 가장 작은 한 묶음인 함수, 클래스 같은 모듈에 대한 테스트
• 프론트엔드에서는 파일구조를 컨테이너/컴포넌트로 나눌 때 컴포넌트에 대한 테스트가 단위테스트 에 해당됨

통합테스트 (integration)

• 여러 모듈끼리 연결이 있는 코드에 대한 테스트
• 객체끼리 데이터를 주고받고 여러 모듈을 핸들링하는 코드에 대한 테스트
• 프론트엔드에서는 파일구조를 컨테이너/컴포넌트로 나눌 때 컨테이너에 대한 테스트, 간단하게 말해 페이지에 대한 테스트
• 어떠한 함수나 기능에 따라 원하는 컴포넌트로 이동 및 상호작용이 이루어 지는 지를 확인한다

인수테스트 (Acceptance)

• 코드의 기능 보다는 비즈니스에 초점
• 애자일 개발 방법론에서 파생됨
• 익스트림 프로그래밍에서 사용하는 용어
• 프로젝트에 참여하는 사람들(ex. 기획자, 클라이언트 대표, 개발자 등)이 토의해서 시나리오를 만들고, 개발자는 이에 의거해 시나리오를 인수 받아 개발
• 시나리오에서 요구하는 것은 누가, 어떤 목적으로, 무엇을 하는가 인데 이런 기능은 API를 통해 드러나며 인수 테스트는 주로 이 API를 확인하는 방식으로 이루어 짐
• e2e 형식을 이용함

e2e(end to end) 형식은 모듈, 코드 품질을 보증하던 테스트와 다르게 코드를 통해 사용자 입장에서 테스트하는 방법을 말합니다. 예시로 들면 Cypress, Selenium 같은 툴로 실제 사용자처럼 개발 환경으로 구성된 사이트에 들어가서 테스트를 하는 코드를 작성하면 e2e라고 말할 수 있습니다.

마치며

테스트 코드를 조사 하기 전까지는
"테스트 코드가 꼭 필요할까?"
"구현을 도와주는 하나의 보조 수단정도 아닌가?"
라고 생각했다. 조사를 하다보니 테스트 코드는 생각보다 중요했고 필수사항이였다. 테스트 코드를 위해서 기존 코드의 설계도 바뀔 수 있고 구현과 테스트는 같은 레벨로 보아야 한다는 것이다. 상황에 맞는 적절한 테스트를 선택해서 활용할 필요가 있다. jest 를 통해 테스트 튜토리얼을 통해 다루어 본 후 프로젝트에 적용할 예정이다. 스켈레톤 UI 나 API 통신이 존재하는 컴포넌트에 대한 단위테스트를 도입하고 각 페이지 별로 통합테스트를 진행하면 좋을 것 같다는 생각이다.

참고 자료1
참고 자료2
참고 자료3