1. 인터페이스를 기준으로 테스트한다
내부 구현을 기준으로 하면
- 결과가 같더라도 로직의 변경마다 테스트코드를 새로 작성해야하고
- 특정 상황에 리액트의 경우 테스트코드에서 상태를 모두 직접 변경해야함
-> 상태를 모두 직접 변경(캡슐화 위배) 해서 내부 구현을 검증하니 상태나 변수명이 변경되면 테스트코드에서도 변경해줘야함(내부구현과의 종속성)
이러한 문제가 있기에 인터페이스를 기준으로 테스트를 진행하게 됩니다
예를 들어 클릭이벤트를 통한 돔 변경을 검증하는 방식으로 테스트를 진행하는 것입니다.
내부구현과의 종속성이 없어 구현이 변경되어도 테스트를 만족한다면 문제가 없어짐
테스트커버리지는 꼭 100%가 되어야 하는가?
테스트 커버리지를 100%로 만족하기위해서는 모든 분기의 테스트를 진행해야합니다
2가지 의문이 발생합니다.
타입을 확인하는 것과 같이 간단한 유틸함수,
함수로 인한 데이터 가공이나 다른 로직이 없이 간단한 데이터를 받아와 ui를 랜더링 하는 것에도 테스트 코드를 작성해야할까?
간단한 함수의 경우 굳이 필요없다 생각하고
코드 제작시에 타입스크립트를 사용함으로써 타입의 정적 분석을 통해 안정성을 챙기려한게 아닐까 생각합니다
로직이 없는 ui를 랜더링의 테스트 까지 필요할까 문제가 발생한다면 어떤 부분에서 문제가 발생했는지 발견하기 쉽고
ui랜더링시 어떤 것이 보여야한다는 것이 데이터에 따라 유동적이므로 낭비일 수 있습니다
이러한 테스트는 앱의 로직의 안정성을 높이는 것이 아니므로 의미있는 테스트가 아닐 수 있습니다
그렇다면 의미있는 테스트는 무엇인가?
데이터를 가공하는 로직, 특정 동작에 변경되는 상태 및 데이터들이 개발자가 의도한 방향으로 변경되는지
확인할 수 있는 것 이라 생각합니다
'Aplication test' 카테고리의 다른 글
테스트 코드의 의의 (0) | 2024.01.26 |
---|---|
리액트 테스트코드 - add (0) | 2023.10.31 |
리액트 테스트코드 - list , header (0) | 2023.10.30 |
리액트 테스트 코드 - 2 (0) | 2023.10.30 |
리액트 테스트코드 - 1 (0) | 2023.10.28 |