1. 테스트는 결함의 존재를 보이는 것이지, 결함이 없는 것을 보이는 게 아니다.:
- 의미 있는 테스트코드는 "내가 구현한 함수가 어떻게 하면 실패할지?"를 고민해서 작성한 것이다.
- 즉, 결함을 보여주는 테스트코드가 가치 있는 테스트코드이다.
- 설계가 얼마나 이상하고, 코드가 얼마나 잘 못짜여져 있는지를 보여주는 게 결국 테스트코드다...
2. 완벽한 테스트는 불가능하다.
- 테스트도 결국에 사람이 만드는 것이기 때문이다.
- 테스트 코드가 배포환경까지 완벽하게 컨트롤하기는 힘들다.
3. 테스트 구성은 가능한 빠르게 시작하는 것이 좋다.
- 어떤 서비스를 시작하든, API를 개발하든, 테스트 코드를 제일 먼저 작성하는 것이 코드 개발의 안정성을 불어넣어준다.
4. 결함은 일반적으로 "모여" 있다.
- 일반적으로 테스트 코드를 작성하지 않은 로직에서 결함이 나타난다.
5. 비슷한 테스트만 반복하면, 새로운 결함을 발견할 수 없다.(살충제 역설)
6. 테스트는 문맥 의존적이다.
- 테스트의 목적은 내가 예상한 결과(내가 예상한 에러O or 에러X)를 검토하는 것이다. 모든 결과는 결국 시나리오와 마찬가지로 앞,뒤 맥락이 있다. 즉, 테스트코드를 작성할 때도 그 앞,뒤 맥락의 상황을 반영해야한다.
7. 사용되지 않을 시스템이나 사용자의 기대에 부응하지 않는 기능의 결함을 찾기 위한 테스트는 부질없다.
1. Unit test: 단위 기능에 대한 테스트 ex. 함수 하나를 두고 보았을 때, 함수의 I/O나 버그를 테스트.
2. Integration test: 여러 기능이 연결된 상태에 대한 테스트
3. E2E test: 백앤드부터 프론트앤드까지 전체적인 과정을 모두 점검하는 테스트
- 서비스를 시작할 때, 가장 먼저 해보는 것이 좋음. 일단 사용자에게 보여주는 것이 잘 나타나는지 테스트하는 것이기 때문.
(출처: https://www.itworld.co.kr/news/152680)
카오스 엔지니어링
은 의도적으로 시스템에 장애를 일으킴으로써, 시스템의 탄력성을 높이는 테스트 코드 방법을 의미한다. supertest
라는 라이브러리를 통해 Integration test를 진행한다.