프론트엔드 TDD (feat -Javascript)

TDD (Test-driven development)

 

테스트를 하는 이유?

• QA팀이 있다면 회사입장에서도 리소스 ( 병목현상, 인건비, 시간) 가 발생한다.
• 개발팀도 QA팀이 뒤늦게 발견한다면 에러를 나중에 수정해야한다.
• 테스트 자동화 
• 에러 발생확률 낮음
• 꼼꼼히 작성한다면 다시 코드를 안봐도 되는 불안감 해소효과??
• 리팩터링하기 부담스럽지 않음
• 유지보수가 용이해짐
• 코드의 품질향상
• 코드의 문서화

 

테스트 피라미드

• Unit Test (단위 테스트){함수, 클래스, 모듈} =>
  Integration Test(통합 테스트){상호작용 테스트} =>
  End to End Test (UI 테스트){사용자 테스트}

 

피라미드라고 부르는 이유?

 

 밑에서 위로 올라갈 수록 리소스가 많이 든다. 가장 쉬운것이 Unit 테스트 이므로 가장 쉽고 시간이 절약된디.

그러나 위로 올라갈수록 복잡해질수록 리소스가 많이 든다.

 

TDD (Test-driven development) 란? 

 

개발 전 테스트 코드를 먼저 작성하여 테스트 주도 개발 방법론이다.

이러한 개발 방법에는 사이클이 존재한다.

 

TDD 사이클, 이미지 출처: https://sehun-kim.github.io/sehun/tdd/

구현 전 작성했기 때문에 Error(Red) -> 

오로지 통과를 위한 목적으로 코드를 적당히 작성 통과 (Green) -> 

해당 코드를 리팩토링 (Refactor) 하여 테스트를 완성한다.

 

 

TDD 순서

 

요구 사항 분석 및 이해 -> 설계 -> 테스트 코드 작성

 

자연스럽게 요구사항분석을 자세하게 보기 됨으로써 하나의 목적에 집중할 수 있게 됨

 

TDD 하기 좋을 때

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

 

CI / CD 에서의 테스트

 

• 지속적인 통합(Continuous Integration) 지속적인 통합
  1. 코드 변경 사항을 주기적으로 빈번하게 머지해야 한다.
  2. 통합을 위한 단계 (빌드, 테스트, 머지)의 자동화
  
  얻을 수 있는 장점
  코드의 퀄리티 향상, 개발 생산성 향상, 버그 수정 용이, 문제점 빠르게 발견
  

 

테스트 툴

 

과거에는 

Test Runner (테스트 실행 후 결과 생성) ex) Mocha 

Assertion (테스트 조건, 비교를 통한 테스트 로직) 따로따로 존재 했었다. Ex) Chai, expect.js, better-assert

물론 요즘에는 Jest 같은 좋은 라이브러리가 나와서 한방에 처리 할 수 있다.

 

특징 및 장점, API에 대해서 알아보려면 

공식문서: https://jestjs.io/

 

설치

 

윈도우

npm i jest --global

 

맥

sudo npm i jest --global

 

간단하게 Jest 를 설치 할 수 있다.

 

환경설정

jest --init

jest init 을 하면 pacakage.json 처럼 가볍게 설정 할 수 있는 커맨드창이 나오고 원하는대로 설정하게 되면

 

jest.config.js 파일이 생성되고

pacakge.json 파일의 scripts의 test에는

 

이렇게 기본값으로 맞춰질것이다.

 

그러나 보통 테스트할때 일일이 명령어를 치는게 귀찮다면

scripts에 --watchAll 을 추가해준다면 저장할때마다 자동으로 테스트가 실행될 것이다.

 

기본적인 사용법

테스트 할 함수를 만들어주고 exports하고

아래와 같이 테스트 함수를 작성해준다음

터미널에 package.json의 scripts에 등록한 npm run test를 하면 끝!

add.js 파일

 

add.test.js 파일

test결과