어떤 것들을 테스트 해야할까?
설계 문제가 있음을 알려주는 테스트의 속성
- 긴 셋업 코드
- 셋업 중복
- 실행 시간이 오래 걸리는 테스트
- 깨지기 쉬운 테스트
e2e 테스트를 하다 보면 자주 발생하는 문제들. 나눌수도 없는데 어쩔 수 없는 걸까?
MTBF(Min Time Between Failures)
작성해야할 테스트의 갯수는 실패간 평균시간(MTBF)를 얼마나 조심스럽게 측정하는지에 달렸다. 어떤 구현에 대한 지식이 신뢰할 만 하다면 그에 대한 테스트는 작성하지 않을 것이다.
ETC
- 개발하려는 프로그램의 규모에 상관 없이 TDD는 가능하다.
- 어플리케이션 수준의 TDD는 쉽지 않다. (1. 여러사람의 협조가 필요, 테스트와 피드백 사이의 길이)
- 프로젝트 중간에 TDD를 도입하려면 한꺼번에 보다는 점진적으로 도입해야 한다.
- TDD와 패턴을 함께하려고 하기 보다는 기능에 대해 테스트를 짜고 설계가 맞춰서 정해지도록 하는 것이 더 낫다.(이렇게 이해하는게 맞는지 잘 모르겠다;;)
- GUI에 대한 자동화 테스트는 만들 수 없다.(Flutter의 integrated test에서는 자동으로 UI e2e 테스트가 가능했던거 같던데...)