- 무엇이 좋은 테스트를 만드는가?
- 테스트를 대하는 태도
- 신뢰할 수 있는 테스트의 중요성
- 무엇이 테스트를 좋게 만드는가?
- 가독성과 유지보수성
- 소스파일안에서 코드는 적절히 구조화 되었는가?
- 무엇을 검사하는가?
- 안정적이고 반복 가능한가?
- 테스트 더블을 잘 활용하는가?
읽기 쉬운 코드가 유지보수도 쉽다
- 가독성과 결함 밀도는 반비례 한다는 연구 결과도 있다. 읽기 어려운 코드일 수록 결함 수가 많다.
- 제품의 구조와 API 가 테스트를 고려하지 않고 만들어졌다면 아무리 날고 기는 테스트 작성자가 와도 결국 끔직한 구조의 이해하기 어려운 테스트밖에 만들 수 없기 때문이다.
구조화가 잘되어 있으면 이해하기도 쉽다
- 아무 구조나 다 코드를 이해하는데 도움이되는 건 아니다. 이해할 수 있는 구조가 필요하다.
- 코드가 도메인 모델이나 머릿속의 개념과 맞지 않아서 나눌 수 있는 명확한 경계를 찾을 수 없다면, 차라리 나누지 않느니만 못할 수도 있다.
- 고주준의 개념을 구현된 코드에 빠르고 정확하게 대입할 수 있는 구조면 된다.
- 결국은 읽기 쉽고, 찾기 쉽고, 이해하기 쉽도록 한 가지 기능에 충실한 테스트가 필요한 것이다.
- 현재 작업과 관련된 테스트 클래스를 찾을 수 있다.
- 그 클래스에서 적절한 테스트 메서드를 고를 수 있다.
- 그 메서드에서 사용하는 객체의 생명주기를 이해할 수 있다.
엉뚱한걸 검사하는 건 좋지 않다.
- 이때 가끔은 테스트의 이름을 너무 믿어버리는 실수를 저지르곤 한다. 보통은 테스트의 이름을 보면 그 테스트가 검사하는 내용을 알 수 , 실제로는 이름과 전혀 관련 없는 것을 검사하는 경우가 종종 있다.
- 올바른 것을 검사하는 것 못지않게 올바른 것을 똑바로 검사하는 것도 중요하다.
독립적인 테스트는 혼자서도 잘 실행된다.
- 테스트가 얼마나 독립적인가를 잘 살펴야 한다.
- 다음 요소와 관련이 있다면 각별한 주의가 필요하다.
- 시간, 임의성, 동시성, 인프라, 기존데이터, 영속성, 네트워킹
- 격리와 독립성이 중요한 잉유는 그서이 없다면 테스트를 실행하고 관리하기 훨씬 어렵기 때문이다.
- 이런한 종속성은 우리가 제어할 수 없다는 특징이 있다.
- 같은 테스트 클래스에 속한 테스트 메서드끼리도 순서를 가정하면 안 된다.
- 이들과의 종속성은 가능하다면 피하는게 최선이고, 아니면 작고 격리된 단위로 구분해서 이 복잡한 상황으로 부터 다른 테스트를 보호해야 한다.
- 방법
- 테스트 더블로 서드파티 라이브러리와의 종속성을 제거한다. 혹은 손수만든 어댑터로 적절히 감싸준다.
- 필요한 자원을 테스트 코드와 같은 위치에 둔다.
- 테스트가 사용할 자원을 직접 만든다.
- 필요한 문맥을 직접 설정하게 한다. 다른 테스트에 의존하지 말자
- 영속성이 필요한 테스트는 in-memory DB 를 활용한다. 시간도 단축되고, 깨끗한 데이터를 훨씬 간단하게 준비할 수 있다.
- 스레드를 사용하는 코드는 비동기식을 구분지어 동시성 문제는 소규모의 전문 테스트 그룹에 맡긴다.
믿은 직한 테스트랑야 기댈 수 있다.
- 믿을 수 없는 테스트
- 아무것도 검사하지 않는 테스트
- 띄엄띄엄 성공하거나 띄엄띄엄 실패하는 테스트
테스트 도구
- 테스트 더블 - 스텁 가짜객체, Mock 객체
- 테스트 프레임워크 - JUnit
- 자동 빌드 도구
요약 (자동화된 테스트를 만드는 데 지대한 영향을 주는 요소)
- 가독성
- 테스트 구조
- 엉뚱한 걸 검사하는 테스트와 그로 인한 문제
- 의심스런 동작을 하느 테스트
- 테스트 필수도구 (테스트 더블, 테스트 프레임워크, 자동 빌드 도구)
software develop engineer