#유닛테스트
1. 하나의 테스트 케이스는 단위 기능 중 하나의 시나리오만 테스트하라.
2. 불필요한 검증 구문을 작성하지 마라. (단위 내의 모든 것에 대해 검증 구문을 작성하지 마라. 대신 테스트하려고 하는 하나의 시나리오에 집중해라.)
3. 각 테스트는 독립적이어야 한다.
4. 모든 외부 서비스와 상태들에 테스트 더블을 사용해라. (그렇게 하지 않으면 공통된 외부 조건을 사용하는 테스트 구문들의 결과가 서로에게 영향을 미친다)
5. 시스템 설정 파일에 관한 단위 테스트를 작성하지 마라. (단위 테스트의 범위가 아니다)
6. 단위 테스트 케이스의 이름은 명확하고 일관되게 테스트의 의미를 반영해야 한다.
#유닛테스트 네이밍 종류
1. 테스트할 기능
- 테스트 메서드를 식별하는 방법으로 주석을 사용하고 있기 때문에, 테스트할 기능만 간단하게 쓰는 것이 더 낫다는 의견이 많다. 또한 코드의 악취를 방지하고, 문서화된 형태의 유닛 테스트를 수행하므로 권장되는 방법이다.
- 예시
- IsNotAnAdultIfAgeLessThan18
- FailToWithdrawMoneyIfAccountIsInvalid
- StudentIsNotAdmittedIfMandatoryFieldsAreMissing2. should_기대결과_When_테스트상태
- 이러한 형태의 네이밍은 많은 사람들이 테스트에 대해 쉽게 이해할 수 있기 때문에 많이 사용된다.
- 예시
- should_ThrowException_When_AgeLessThan18
- should_FailToWithdrawMoney_ForInvalidAccount
- should_FailToAdmit_IfMandatoryFieldsAreMissing3. when_테스트상태_Expect_기대결과
- 예시
- When_AgeLessThan18_Expect_isAdultAsFalse
- When_InvalidAccount_Expect_WithdrawMoneyToFail
- When_MandatoryFieldsAreMissing_Expect_StudentAdmissionToFail4. given_사전조건_When_테스트상태_Expect_기대결과
- 이러한 접근법은 행동 주도 개발(BDD)의 일부로 개발된 네이밍 컨벤션에 기초한다. 이 아이디어는 테스트를 세개의 파트로 나누어 전제 조건, 테스트 상태, 기대 결과가 위 형식대로 네이밍되는 형태이다.
- 예시
- Given_UserIsAuthenticated_When_InvalidAccountNumberIsUsedToWithdrawMoney_Then_TransactionsWillFail
#마인파울러의 추천 테스트스타일
- https://martinfowler.com/bliki/GivenWhenThen.html
- 행동 주도 개발(BDD)
- given : 사전조건
- When : 테스트상태
- then : 기대결과
#더 고민해보기
- 테스트도 설계 및 기법이 존재
https://engineering.linecorp.com/ko/blog/testing-optimization/#foot1
