- Test Driven Development: 실제 코드 짜기 전 단위 테스트부터 짜라.
- 1) 실패하는 단위 테스트 작성할 때 까지 실제 코드 짜지 않는다.
- 2) 컴파일은 가능하지만 실행이 실패하는 정도로만 단위 테스트 작성.
- 3) 현재 실패하는 테스트를 통과할 정도로만 실제 코드 작성.
- 이 규칙을 따르면 개발과 테스트가 대략 3초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나온다.
- 깨끗한 테스트 코드 유지: 테스트 코드가 지저분할수록 코드를 변경하기 어려워진다.
- 테스트는 유연성, 유지보수성, 재사용성을 제공. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.
- 테스트 코드에서 가장 중요한 것은 가독성.
- Build-Operate-Check패턴. 첫 번째 부분은 테스트 자료를 만들고, 두 번째 부분은 테스트 자료를 조작하며, 세 번째 부분은 조작한 결과가 올바른지 확인한다.
- 테스트 코드에 사용하는 API코드를 그대로 쓰는 게 아니라 API위에 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하여 테스트 코드 작성: DSL(Domain Specific Language)
- 이중 표준: 테스트 코드는 단순, 간결, 표현력 풍부해야 하지만 실제 코드만큼 효율적일 필요는 없다. 실제 환경과 테스트 환경의 요구사항이 다르기 때문. 예를 들어 임베디드 시스템에서는 자원과 메모리 한정적. 그러나 테스트 환경은 아님.
- 어떤 사람들은 테스트 함수마다 assert가 한 개만 있어야 한다고. 그러나 이렇게 테스트를 분리하게 되면 중복되는 코드가 많아진다.
- Template Method 패턴을사용하면 중복 제거 가능. given/when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 두면 된다. 또는 완전 독자적인 테스트 클래스를 만들어 @Before 함수에 given/when을 구현하고, @Test 함수에 then 부분을 넣는다.
- 테스트 함수마다 한 개념만 테스트하라 -> 이 규칙이 더 낫다.
- FIRST 규칙
- 1) Fast: 테스트가 느리면 자주 돌릴 엄두를 못 냄
- 2) Independent: 각 테스트는 서로 의존하면 안 된다. 어떤 순서로 실행해도 괜찮아야 함.
- 3) Repeatable: 어떤 환경에서도 반복 가능해야. 실제 환경이나 QA환경이나
- 4) Self-evaluating: 테스트는 불리언 값으로 결과를 내야. 성공 아니면 실패.
- 5) Timely: 테스트는 적시에 작성. 단위 테스트는 실제 코드 구현하기 직전에 구현하라.
카테고리 없음