유닛 테스트
- 테스트를 최대한 격리
- 가능하면 유닛 테스트 하나 당 하나의 단언문(Assertion)을 작성하는 것을 권장
장점
1. 테스트가 실패하면 어디가 문제인지 정확하게 알 수 있다
- 함수나 컴포넌트를 테스트 할 때 의존성을 표시
- 컴포넌트가 의존하는 다른 함수나 컴포넌트가 있으면 실제 버전 대신 테스트 버전을 사용
👉🏽 문제 발생 시 다른 어떤 것이 아닌 해당 유닛의 문제임을 알 수 있도록.
- 내부 테스트 시행
- 격리 상태에서 컴포넌트를 테스트하면 상태(state)에 대한 것만 테스트할 수 있다. (애플리케이션 변경하는 다른 컴포넌트 X)
단점
1. 사용자가 소프트웨어와 상호작용하는 방식과는 거리가 있다.
(사용자가 소프트웨어와 상호작용하는데 실패해도 테스트는 통과할 수 있다. 또는 테스트가 실패해도 사용자가 소프트웨어와 상호작용하는 데는 문제가 없을 수도 있다. )
2. 리팩토링 시 테스트가 실패할 수도 있다.
(리팩토링 : 동작을 변경하지 않고 소프트웨어 작성 방식을 변경하는 것.)
👉🏽 동작을 변경하지 않았는데도 작성 방식을 바꾸는 것만으로 테스트가 실패할 수 있기 때문에 이런 점은 단점이 된다.
기능 테스트
- 테스트하는 특정 동작이나 유저 플로우와 연관된 모든 단위를 포함
- 보통 이어지는 일련의 기능들을 하나의 테스트 구문(
test())으로 묶어서 작성. (안에 여러 개의 단언문(Assertion))
장점
1. 사용자가 소프트웨어와 상호 작용하는 방식과 밀접
-
테스트에 통과하면 사용자에게 문제가 없고 실패하면 사용자에게 문제가 일어날 가능성이 높음을 의미
-
리팩토링을 해도 동작이 동일하게 유지되는 한 테스트 통과
단점
1. 실패한 테스트를 디버깅 하기 어렵다.
- 어떤 부분의 코드가 테스트 실패의 원인인지 정확히 알 수 없다.
