👊 오늘의 공부
- Cypress 강의 듣기
=> 자바스크립트로 E2E 테스트 코드를 작성함으로써 사용자 중심의 흐름으로 ‘검증’ 가능한 앱을 만들 수 있다.
*cypress 깔고 열기
npm install cypress --save-dev
./node_modules/.bin/cypress open
1)Counter 앱 테스트 코드 작성
2)계산기 앱 테스트 코드 작성
=> 테스트 코드의 두려움 극복하기 -> 자신감으로 바꾸기
💪 테스트를 작성해야 하는 이유
- 애플리케이션이 요구 사항에 맞게 동작하는지를 검증하는 행위
- DB에 데이터를 입력하는 API를 개발 -> API 호출 -> DB 값 검증
- 디자인 시안에 맞게 HTML/CSS를 작성 -> 브라우저에서 실제 렌더링한 결과를 확인
- 새로운 기능을 추가하기 위해 기존 모듈을 리팩토링 -> 영향을 받는 다른 모듈의 실행 결과를 확인
- 버그를 수정하기 위해 기존 함수를 수정 -> 버그가 수정 확인&영향을 받는 다른 모듈의 실행 결과를 확인
- 개발 환경에서 테스트된 어플리케이션을 리얼 환경에 배포 -> 배포 과정에서 발생한 문제가 없는지 확인
- 개발과 테스트
- 개발자는 사실상 코드를 작성하는 것보다 더 많은 시간을 테스트에 사용
💡 테스트 자동화
- 장점
- 사람이 수행해야 하는 반복된 테스트를 자동화 할 수 있음 (비용 감소)
- 사람이 수행하는 것보다 훨씬 빠르게 테스트할 수 있음
- 사람이 수행하는 것보다 더 신뢰할 수 있음
- 단점
- 감각적인 요소(시각, 청각) 등 사용자 경험과 관련된 문제를 찾아낼 수 없음
- 실제 환경에서 벌어지는 다양한 상황을 자동화하기 어려움 (네트워크, 디바이스 관련 등)
* 테스트 자동화는 누가 하는가?
=> QA 팀, 개발자가 둘다 해야 함.
🧐 개발자가 테스트 작성을 해야하는 이유
- 개발 품질
- 개발자는 작성한 프로그램의 퀄리티에 대한 책임이 있음
- QA에 넘기기 전에 기본 요구사항을 모두 만족하는지에 대한 검증은 개발자가 해야 함
- 자동화된 테스트를 작성해 두지 않으면, 어플리케이션이 복잡해 질수록 테스트 비용이 증가함
- 이 경우 개발 기간이나 인력 등은 한정되어 있기 때문에, 테스트를 소홀히 하게 되는 경우가 많음
- 그렇지 않은 경우 QA 와의 커뮤니케이션 비용이 늘어나, 업무 효율이 떨어지게 됨
- 코드 품질
- 코드 품질을 위해서는 계속해서 리팩토링 등의 개선 작업이 필요
- 이 과정에서 기존에 잘 동작하던 프로그램을 망칠 수 있기 때문에 적극적으로 코드를 개선하지 않게 됨
- 신뢰할 수 있는 자동화된 테스트가 있으면 적극적으로 코드를 개선할 수 있음
- 두려움(Fear) -> 자신감(Confidence)
🫵 테스트의 종류
- 단위(Unit) 테스트 (계산기같은 테스트 코드)
- 모듈(함수/클래스) 단위의 테스트
- 작성 비용이 적게 들고 실행 속도가 빠름
- 실패했을 때 문제가 생긴 부분을 비교적 정확하게 파악할 수 있음
- 통합 테스트
- 주로 단위 테스트보다 큰 범위의 테스트를 의미
- 개별 모듈들이 연결되어 제대로 상호작용 하는지를 테스트
- 단위 테스트에 비해 실패 시 문제가 생긴 부분을 정확히 파악하기가 어려움
- E2E 테스트
- 실제 사용자가 사용하는 것과 같은 조건에서 전체 시스템을 테스트
- 단위/통합 테스트에 비해 작성이 어렵고 실행 속도가 비교적 느림
- API 서버, DB등의 외부 서비스들을 모두 사용하여 통합된 시스템을 테스트
🙈 좋은 테스트란?
- 실행 속도가 빨라야한다.
- 빠른 피드백은 개발 속도를 향상시켜준다.
- 너무 느리면 테스트를 자주 실행하지 않게 된다.
- 내부 구현 변경 시 실패하지 않아야 한다.
- 리팩토링할 때 테스트가 깨진다면 ? 오히려 코드 개선을 방해
- 자주 변하는 로직과 변하지 않는 로직을 구분
- 버그를 검출할 수 있어야 한다.
- 소스 코드에 버그가 있어도 검출하지 못한다면 잘못된 테스트
- 테스트가 기대하는 결과를 구체적으로 명시하지 않으면 버그를 검출할 수 없음
- 테스트의 결과가 안정적이여야 한다.
- 특정 환경에서만 실패하거나, 실행할때마다 결과가 달라지는 테스트는 신뢰할 수가 없음
- 외부 환경의 영향을 최소화해서 동일한 결과를 최대한 보장할 수 있는게 중요함
- 의도가 명확히 드러나야 한다.
- 가독성: “기계가 읽기 좋은 코드” -> “사람이 읽기 좋은 코드”
- 테스트 코드를 보고 한 눈에 어떤 내용을 테스트하는지를 파악할 수 있어야 함
🐻 테스팅 ROI(투자 수익률)
- 테스트 코드 작성과 유지보수도 비용이므로 잘 작성해야 한다.
- 불필요한 테스트나 잘못짜여진 테스트는 차라리 없는게 나음
- 비용 대비 효과가 충분한가?
- 테스트를 작성하는 비용에 비해 얻을 수 있는 효과가 더 큰지가 중요
- 로직이 거의 없는 코드는 따로 테스트하지 않아도 됨
- 테스트 범위에 대한 조절이 필요함
- 커버리지 100%를 목표로 하는 것은 비효율적이다.
- 복잡한 어플리케이션일수록 적절한 선을 찾는 것이 중요
* 방법
1)기능 구현이 되어있는 git에서 받아와 한사이클을 돈 후 한번에 다시 작성
2)TDD형태로 테스트 코드를 먼저 작성하고, 기능 구현도 직접하기.
*TDD란? Test Driven Development 라고 불린다.
=> 테스트부터 작성하는 개발 방식이며, 작동하는 깔끔한 코드를 지향한다 (clean code 지향)
방법
=> 1. 실패하는 테스트를 만든다.
=> 2. 해당 테스트를 통과할 수 있는 코드를 만든다.
=> 3. 테스트에 성공한다.
=> 4. 작성한 코드에서 중복을 제거한다.
=> 5. 다시 1번으로 돌아가서 작업한다.
=> 정리: red(테스트 실패) -> green(테스트 성공) -> refactor(리팩토링) -> 다시 1번으로 돌아가기
중요한 것
=> 문제 설정: TDD에서 가장 중요한 것, 비즈니스 로직에 대한 고민이고 분석이다.
(테스트는 비즈니스 로직을 잘 반영하는 것이어야 하므로, 문제 설정에 따라 작성하는 테스트가 달라진다.)
'javascript' 카테고리의 다른 글
💪REST API 설계 원칙 (0) | 2022.09.28 |
---|---|
[JavaScript] addEventListener에서의 this 바인딩 (0) | 2022.08.18 |
JavaScript로 알고리즘 준비하기(1) - 정규 표현식(문자열 갖고놀기) (0) | 2022.04.14 |