테스트 생성자
- 두가지 단점이 있다.
-
테스트 간 결합도가 높아진다.
- 테스트는 서로 격리돼 실행해야 한다. (수정도 독립적이어야 한다.)
-
테스트 가독성이 떨어진다.
- 테스트만 보고 전체 그림을 볼 수 없다. 테스트 메소드가 무엇을 하는지 이해하려면 클래스의 다른 부분도 봐야한다.
별로다
비공개 팩토리 메소드
-
테스트가 서로 결합되지 않는다.
-
읽기 쉽고 재사용이 가능하다.
-
메소드 이름에 의도가 드러나 있으므로 가독성이 좋고, 메소드 내부를 알아볼 필요가 없다.
-
모든, 또는 거의 대부분의 테스트에 사용되는 경우 테스트 생성자를 사용할 수도 있다.
DB연결이 필요한 통합테스트
단위 테스트 명명법
- 표현력 있는 이름 붙이는 것이 중요하다.
- 도움 되지 않는 방법
테스트 대상 메소드: 테스트 중인 메소드의 이름
시나리오: 메소드를 테스트하는 조건
예상 결과: 현재 시나리오에서 테스트 대상 메소드에 기대하는 것
-
동작 대신 구현 세부사항에 집중하게끔 부추기기 때문에 분명히 도움이 되지 않는다.
-
간단하고 쉬운 영어 구문이 효과적이다.
단위 테스트 명명 지침
-
엄격한 명명 정책을 따르지 않는다. 복잡한 동작에 대한 높은 수준의 설명을 이러한 정책의 좁은 상자 안에 넣을 수 없다. 표현의 자유를 허락한다.
-
문제 도메인에 익숙한 비개발자들에게 시나리오를 설명하는 것처럼 테스트 이름을 짓자.
-
단어를 밑줄 표시로 구분한다. 특히 긴 이름에서 가독성이 향상 된다.
-
테스트 이름에 SUT의 메소드 이름을 포함하지 마라.
코드를 테스트하는 것이 아니라 애플리케이션 동작을 테스트 하는 것이다. 따라서 테스트 대상 메소드의 이름은 중요하지 않다. SUT는 단지 진입점, 동작을 호출하는 수단일 뿐이다. 테스트 대상 메소드의 이름이 변경될 수도 있는데, 이렇게 되면 테스트 이름도 바꿔야 한다.
이처럼 동작 대신 코드를 목표로 하면 해당 코드의 구현과 테스트 간의 결합도가 높아진다.
유틸리티 코드는 예외다.
매개변수화된 테스트
-
동작의 복잡도가 클수록, 설명하려면 여러가지 테스트 케이스가 필요하다. 이러한 케이스들을 하나의 메서드로 묶을 수 있다.
-
매개변수화된 테스트를 사용하면 코드를 줄일 수 있지만, 비용이 발생한다.
메소드가 나타내는 사실을 파악하기가 어려워 진다. (매개변수가 많을수록 더)
-
긍정적인 테스트 케이스와 부정적인 테스트 케이스를 나눈다.
-
동작이 너무 복잡하면 매개변수화된 테스트를 사용하지 말자.
