Why? — 왜 사용해야하는지?Why Cypress?Advantage DisadvantageHow — 제안 사항테스트 코드 작성 시점작성할 테스트 코드작성 방법작성 예시(임시)Reference
Why? — 왜 사용해야하는지?
- 프로젝트를 진행하면서 기능 구현 + 리팩토링이 병행 될 것인데 이에 대한 방어 구책이 필요함.
- 특히 함께 협업할때 다른 사람이 구현한 기능을 수정하거나 할때
→ 원하는 기능이 작동되는 것에 대한 검증
- 기능 구현에 대한 명세서
- 내가 어떤 기능을 구현했고, 다른 사람이 어떤 기능을 구현했는지 확인하는 명세서가 필요함.
- 구현 한 사람 외 다른 사람이 리팩토링하거나 에러를 수정할때, 어떤 부분이 검증되어야하는지 명세 확인 반드시 필요함.
- 기획서는 문서를 켜놓고 확인해야하며, 테스트 코드를 사용하는 경우 IDE로 전부 확인가능.
→ 불필요한 노동 감소
Why Cypress?
- Cypress는 E2E테스트이다.
E2E로 실제 사용자 동작을 테스트 할 수 있음.
— 실제 상황에서 발생할 수 있는 에러를 사전에 발견할 수 있다.
— 수동으로 테스트할 때 시간이 많이 걸리거나, 놓칠 수 있는 것들을 반복테스트하기에도 유용하다. 내가 구현한 기능이 매번 수동으로 테스트하지 않고, 자동으로 모두 정상적으로 동작한다는걸 확인할 수 있다.
- React, Vue 라이브러리나 프레임워크에 종속되지 않음.
- 사용 유저가 많아서 정보를 찾기 쉬움.
Advantage
- 자신감을 가지고 리팩토링 할 수 있다.
- 작업 코드가 망가지지 않았다는 확신을 가질 수 있다.
- 문서화하여 공유할 수 있다.
- 테스트 코드만으로 동료가 구현한 기능의 동작을 알 수 있다.
- 코드의 목적성을 파악하기 수월하다.
Disadvantage
- 테스트코드 작성법에 대한 학습 비용
- 테스트코드를 작성하느라 사용 되는 비용
⇒ 테스트 코드를 최대한 최소화하기. 한명이 주도적으로 테스트 코드를 작성애 대한 템플릿을 제공하고, 템플릿 수정하는 정도로 테스트 코드를 사용할 수 있도록 하기.
- 테스트 코드의 퀄리티가 좋지 않을 수 있다.
How — 제안 사항
테스트 코드 작성 시점
- 특정 기능이 완료되면 완료된 기준으로 테스트 코드 작성
- 기능 구현 완료시 데일리로 스크럼하고 문서에 표시하기
작성할 테스트 코드
- 테스트 코드가 필요하다고 판단 되는 필수 기능 위주 로만 작성
- 테스트 코드가 필요하다고 판단되는 부분은 각자 기능, 혹은 페이지 단위로 범위를 나누고 정의하여 노션에 명세하여 공유할 것.
- 명세한 테스트 기능은 노션 코멘트 기능을 사용하여 댓글로 의견 나누기
→ 이게 꼭 필요한 테스트 코드일까요? 혹은 이 부분은 테스트가 필요할 거서 같아요 의견 나누면서 보안하기.
- 구현해야하는 기능이 많아지면, 핵심 기능 외에는 테스트 하지 않기.
- 핵심기능에 대한 정의를 다 같이.
- 테스트 커버리지가 100% 일 필요는 없음. 굿 !
(예시) 로그인 및 인증 성공 실패, 통신 실패시 alert 등등
작성 방법
- 다혜가 필요한 첫 테스트 코드들을 전부 다 작성하여 Template화 하여 제공,
(예시) 특정 값을 입력하고, click하고, 실패시 유효성 alert하는 테스트 코드
⇒ 입력값(목업데이터)만 바꾸고, click할 버튼(타겟)만 바꾸면 사용할 수 있음.
- 기능이 리팩토링되거나 테스트코드 수정이 필요한 경우?
→ 처음 사용되는 테스트 코드와 유사하게 수정, 및 공식문서 참조하여 각자 수정
→ 다혜한테 물어보거나 그냥 수정 요청도 OK
- TDD 방식 적용 X (테스트 코드를 먼저 작성하고, 기능 구현) ⇒ 오래 걸림
- BDD 방식 적용 (사용자 행위 생각하여 테스트 코드)
- 테스트 코드 리팩토링 혹은 테스트 코드 구조에 대한 제안은 언제나 환영
작성 예시(임시)
command를 사용하여 추상화 할 수 있음.
