학습계기
예전에 학과전공, 정보처리기사 자격증을 얻기 위해 공부하던 중 많이 들었던 TDD에 대해 최근에 관심이 생기기 시작하였다.
맨 처음 개발을 시작할 때 우선 여러가지 기술스택에 대하여 익혀보고 프로젝트를 설계하여 적용해보기에 급급했었다.
기술스택들에 대하여 어느정도 익숙해짐을 느끼면 보다 깊은 이해를 위해 공식문서들을 활용하여 확실한 지식을 얻으려고 노력하고 있었다.
나는 디자인-개발-테스트의 과정으로 프로젝트들을 진행하였는데 이 과정에서 모든 예외케이스에 대해 문제가 없을 줄 알았으나 항상 테스트 과정에서 여러이슈들을 발견하게 되었고, 개발한 코드에 대해 리팩토링 하는 과정이 자주 반복되었다.
위와 같은 과정에서 나의 코드의 불확실성에 대하여 고찰하게 되었고, 비슷한 이슈들의 해결방법 중 하나로 TDD 방법론이라는 키워드를 얻게되었다.
TDD 방법론에 대해 학습하고 프로젝트를 설계해보며 직접 장단점을 느껴보려고 한다.
TDD(Test Driven Development)
TDD는 테스트 주도 개발이라고 한다.
반복 테스트를 이용하여 테스트 코드에 기반을 맞추어 실제 코드를 작성해나가는 소프트웨어 방법론이며 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드들을 추가하는 단계를 반복한다.
테스트 코드를 먼저 작성함으로써 실제 코드가 나아가야 할 방향을 잡고 가는 것이다.
실제 코드를 작성하고 리팩토링 과정에서는 기존의 기능은 유지하고 실제 코드의 디자인을 개선해 나가는 방향을 취할 수 있다고 한다.
개발주기
- RED 단계 : 실패하는 테스트 코드 작성
- Green 단계 : 테스트 코드를 통과하는 실제 코드 작성
- Blue 단계 : 중복 제거, 가독성 향상 등 리팩토링 과정 수행
중요한 점은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과 실패하는 테스트를 통과하는 최소의 실제 코드를 작성하는 것이다.
이를 통해, 실제 코드에 대해 명확한 의미 부여와 불필요한 설계를 줄여나가는 것에 집중하는 것이다.
코드 테스트
TDD의 기초적인 이론과 주기들에 대하여 학습하고 느낀점은 TDD가 아닌 방법의 개발을 진행했을 때와의 차이점은 테스트 코드의 부재라는 점이였다.
실제로 개발에 있어 언제나 테스트 과정을 거치고 있었다고 생각한다. 로그를 찍어보거나 UI가 정상적으로 렌더링이 된다거나 항상 로컬 화면에서 일종의 테스트 과정을 거쳤기 때문이다. 하지만 말했듯이 이는 기능적인 실제코드일 뿐 테스트 코드를 작성하는 과정은 생략되어있다.
과정을 돌아보니 나의 TDD방법론의 학습계기에 도달할 수 있었다. 바로 불확실성이다. 프로젝트의 규모가 더 커져 다양한 기능들이 구현된다면 불확실성에 대한 문제점이 언제 발생할지 모르고 리팩토링에 대해 망설이며 기술부채가 증가하는 악순환이 발생할 수 있겠다는 생각을 하게 되었다.
테스트 코드가 존재한다면 일종의 명세서 역할을 수행하여 결함에 대한 예방의 효과를 얻어볼 수 있겠다고 생각하며 직접 경험해보기로 마음 먹게되었다.
프론트엔드 테스트의 종류
정적 테스트
런타임 이전에 테스트를 수행하는 방법으로 많은 사람들이 typescript를 통해 사용하고 있다.
코드 컨벤션과 관련된 eslint 역시 정적 테스트 역할을 수행한다.
단위 테스트(Unit)
최소 단위의 기능 동작을 테스트하기 위해 사용하는 방법이다.
컴포넌트의 렌더링, 기능 함수 등의 가장 기본적인 코드를 테스트한다.
대표적으로 Jest 프레임워크를 활용하여 javascript, typescript로 작성된 코드를 테스트 할 수 있다.
통합 테스트(Intergration)
단위 테스트에서 최소 단위의 기능 테스트가 이루어졌다면 통합 테스트에서는 이러한 단위 테스트들이 통합되어 제대로 상호작용하는지를 테스트한다.
단위 테스트에서 보다 넓은 범위의 테스트를 진행하며 상태변화에 따른 UI 렌더링, UI와 API간의 상호작용 등에 대해 테스트한다.
대표적으로 Jest와 React Testingg Library를 함께 사용하여 테스트한다.
React Testingg Library는 실제 브라우저 DOM을 기준으로 테스트를 작성하는데 유저에게 보여지는 화면을 기준으로 하여 테스트 코드를 작성해나가는 것이다.
예를들어 <h1>TDD 방법론</h1>이라는 DOM에 대해 <h1>태그에 집중하는 것이 아닌 TDD 방법론 텍스트에 집중한다.
E2E 테스트(End to End)
단위 테스트를 통해 함수와 컴포넌트들을 테스트하고 통합 테스트를 통해 서로 다른 컴포넌트와 함수들의 상호작용을 테스트하였다.
마지막으로 E2E 테스트를 통해 종단(Endpoint)간의 테스트를 통해 사용자 입장에서 웹을 사용하는 상황을 가정하여 테스트를 수행하는 것이다.
대표적으로 프론트엔드 개발자들의 편의에 중점을 맞춘 Cypress 테스팅 도구가 있다.
빠르고 간편하게 테스팅을 진행할 수 있어 좋은 경험을 제공한다고 한다.
마치며
오늘은 TDD 방법론을 찾게된 이유와 방법론의 긍정적인 효과에 대해 학습해보았고, 프론트엔드에서의 테스트 종류들에 대해 알아보는 시간을 가졌다.
구체적인 사용방법과 프로젝트에 녹여보는 과정을 통해 깊게 학습할 것이고 이 과정에서 겪은 이슈들을 중점으로 앞으로 테스팅 관련 포스팅을 작성해야겠다.
