테스트란 마우스로 클릭하는거(api 요청 등) 대신해주기!
기능을 검사해주는 코드를 만들어야 한다고?
기능 만들기도 바쁜데?
업데이트 배포를 한다고 생각해보자!
개발자들이 어떤 프로젝트를 성공적으로 1차 배포하고 이후에 2차 업데이트 배포를 했다고 가정해보자. 개발자들은 며칠 후에 1차에서 멀쩡하던 기능에 에러가 생긴 것을 발견하게 된다. 1차 때는 잘 돌아가던 기능들에 에러는 왜 생겼을까?
그 이유는 2차 배포 다시 말해 업데이트 배포한 코드들이 이전 배포한 기능에 영향을 주고 있는 것이다.
예를 들면 업데이트 배포때 배포한 결제기능이 1차 배포때 배포한 상품관련 기능에 연관된 코드를 가지고 있어 에러를 보게 되는 것 입니다.
그럼 과연 하나의 기능에만 영향을 미친다고 확신할 수 있을까?
만약 아니라면 버전1부터 길고긴 버그수정의 기간을 가져야 한다.
이런 힘든 버그잡는 과정을 테스트코드는 조금 더 수월하도록 도와주고 있다.
서비스의 사이즈가 커질수록 테스트 코드의 유용함이 커지며, 버그 수정의 과정이 편리해진다!!
기능 만들 때 테스트코드를 함께 만드는 습관을 들이자!!
기능과 테스트코드는 한 세트!!
테스트 하는 방법은 다양하다!
- 버튼 클릭과 같은 개별 기능 단위테스트
- 여러 기능 한꺼번에 통합테스트
- 접속해서 로그인하고 구매하는 등 시나리오가 있는 E2E(End to End)테스트 => 시나리오 테스트라고도 한다!!
어떻게 하면 되는건데?
=> Jest라는 테스트 전용 프레임워크를 사용해서!
index.spec.ts라고 만들어도 됨!
나만의 가짜 백엔드 API만들고 사용(mocking)하기!
Test-Driven-Development , 테스트 주도 개발을 의미한다. 보통의 개발 과정은 다음과 같다. 요구 사항을 정의하고, 디자인이 나오고, 이를 토대로 실제 코드를 작성 하고 테스트를 진행한다.
하지만 TDD는 테스트 코드를 먼저 작성하고 그 후에 테스트를 통과하기 위한 최소한의 실제 코드를 작성한다. 그 다음에 코드를 리팩토링한다.
TDD 방식을 왜 쓸까?
=> 테스트 코드 만들기를 미루지 말고 테스트 코드를 먼저 만들고 기능을 만들자!
=> 테스트 코드를 만드는 문화를 가지자!