[CS study] TDD의 중요성

개요

• TDD란?
• 왜 TDD를 할까?
• 테스트 종류
• Jest사용해보기

---

TDD(Test Driven Development)

작성하고자 하는 코드가 어떤 일을 할 것인지를 묘사하고 동작을 검증할 때 테스트 코드를 먼저 작성하고 빠르게 테스트를 진행하며 개발하는 방법

 

TDD cylcle

순서)

요구사항 분석 및 이해 => 설계 => 테스트 코드 작성
요구사항 분석에 집중하여 목적을 명확하게 파악하게 됨

 

사용하기 좋은 상황)

• 요구사항이 명확할 때
• 비즈니스 로직
• 협업 시 문서(명세서) 역할
• 코드리뷰

 

 

 

 

---

Why?

1. 코드의 퀄리티 상승 및 비용절감
   
   • 코드의 결함을 개발 주기의 초기에 발견하는데 도움이 되어 후에 수정하는데 있어 드는 비용을 줄일 수 있다.
   • 요구사항에 충족하는 코드인지 재확인이 가능하다.
   • 빠른 피드백으로 코드의 퀄리티를 상승시킬 수 있다.
2. 개발시간 단축
   • 후에 발견 될 결함을 초기에 발견함으로써 최종적인 개발시간이 줄어들 수 있다
   • 근데 TDD 작성하고 검증하는데 드는 시간도 있어서 나는 잘 모르겠다.
3. 문서화
   • 잘 짜인 테스트코드는 그 자체가 문서로 팀원들과의 의사소통에도 도움을 준다.
4. 개인의견
   • TDD에 사용되는 방법을 통해서 브라우저에서 랜더링 해보지 않아도 잘 동작되는 컴포넌트를 개발 할 수 있게 되어 개발 시간이 줄어들 수 있을 것이라 생각이 된다.
   • unit test 작성 간 작동 간에 발생할 수 있는 다양한 에러에 대해서 생각할 수 있어 여러 방면으로 고민을 하게 될 것 같고 그 외에 발생한 에러에 대해서 생각하지 못했던 부분을 발견하게 될 것이라 생각한다.

---

테스트 종류 (Frontend)

위로 갈수록 리소스가 많이 든다.

 

 

1. Unit Test (단위 테스)

코드베이스의 테스트 유닛을 말하며, 어떤 함수(컴포넌트)를 직접 호출해 리턴값이 제대로 나왔는지를 확인하는 방법
얕은 렌더링이 자주 사용 됨

• 테스트하는 단위가 작아서 테스트에 통과하지 못했을 경우 정확히 어떤 부분이 문제인지 알기 편하다
• 몇 백개의 Unit Test를 진행해도 수 초밖에 걸리지 않는다는 장점이 있다
• 정확한 스타일을 렌더링하는지 알기 어려워 Snapshot Test단계가 필요한 이유가 된다.

얕은 렌더링(shallow Render) : 한 단계의 깊이만 렌더링하는 것으로 자식 컴포넌트는 렌더링하지 않고 테스트하고자하는 컴포넌트 자체만 렌더링하고 싶을 때 사용되는 방법 

 

2. Snapshot Test (통합테스트)

렌더링 된 컴포넌트의 snapshot을 찍어 진행되며 최초 테스트 진행 시 컴포넌트의 snapshot을 저장해 이후 컴포넌트의 마크업 및 스타일의 변경을 확인

• 대표적인 React Testing 프레임워크인 Jest에서는 렌더링 된 컴포넌트 마크업의 snapshot을 찍는다
• 코드를 수정했을 때 이 테스트를 통과했다면 컴포넌트의 변경이 없는 것이며 로직이 변경할 때 의도치 않게 컴포넌트의 외관에 영향을 주었다면 테스트를 통화하지 못한다.
• 자체 유지보수의 어려움도 있기에 많이 사용하면 오히려 효율이 좋지 않다.

3. E2E Test (UI 테스트)

최상위에서 진행되는 테스트이며 크롤링과 비슷한 방법으로 브라우저에 보여지고 있는 컴포넌트들을 사용자가 사용하듯 상호작용하는 방식

• 굉장히 느리고 디버깅이 어렵다
• 각 컴포넌트들이 복합적으로 얽혀 일어날 수 있는 문제를 확인할 수 있다.

개인 다짐 : E2E Test까지는 진행하지 못하더라도 Jest를 이용해서 꾸준하게 TDD를 연습해보는 것이 중요할 것 같다.

---

Jest 사용해보기

관련포스트

 

 

 

 

 

 

참고자료 : OKKY , FEConf Korea , 블로그1 , 블로그2