9. 단위 테스트

티스토리 뷰

study/클린코드

pansy0319 2021. 6. 10. 22:44

TDD 법칙 세 가지

TDD의 법칙
- 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다
- 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다
- 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다
이 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다
- 테스트 코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다

깨끗한 테스트 코드 유지하기

지저분한 테스트 코드를 내놓으나 테스트르르 안 하는건 오히려 더 못하다
- 테스트 코드가 지저분할 수록 변경하기 어렵고 테스트 코드는 점점 복잡해지고 실패 케이스를 통과시키기 어려워진다
- 테스트 코드는 계속해서 늘어나는 부담이 되버린다
테스트 코드는 실제 코드 못지 않게 중요하다
- 테스트 코드는 이류 시민이 아니다
- 테스트 코드는 사고와 설계와 주의가 필요하다
- 실제 코드 못지 않게 깨끗하게 짜야 한다
테스트는 유연성, 유지보수성, 재사용성을 제공한다
- 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다
- 테스트 케이스가 있다면 변경이 두렵지 않다
- 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다
- 테스트 커버리지가 높을수록 공포는 줄어든다
- 실제 코드를 점건하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다
- 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다

깨끗한 테스트 코드

깨끗한 테스트 코드는 가독성이 좋아야 한다
- 명료성, 단순성, 풍부한 표현력이 필요하다
- 최소의 표현으로 많은 것을 나타내야 한다
BUILD-OPERATE-CHECK 패턴
- 1. 테스트 자료를 만든다
- 2. 테스트 자료를 조작한다
- 3. 조작한 결과가 올바른지 확인한다
도메인에 특화된 테스트 언어
- API 위에다 함수와 유틸리티를 구현한 후 함수와 유틸리티를 사용하므로 테스트 코드를 짜기도 읽기도 쉬워진다
  - 이렇게 구현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 된다
  - 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어다
이중 표준
- 테스트 코드는 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다
- 테스트 환경은 자원이 제한적일 가능성이 낮다
- 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다
  - 메모리나 CPU 효율과 관련 있는 경우
  - 코드의 깨끗함과는 철저히 무관

테스트 당 assert 하나

F.I.R.S.T

Fast 빠르게
- 테스트는 빠랄야 한다
Independent 독립적으로
- 각 테스트는 서로 의존하면 안 된다
- 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다
Repeatable 반복가능하게
- 테스트는 어떤 환경에서도 반복 가능해야 한다
- 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생기고
  환경이 지원되지 않기에 테스트를 수행하지 못하는 상황에 직면한다
Self-validating 자가검증하는
- 테스트는 bool 값으로 결과를 내야 한다
- 테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관저깅 되며 지루한 수작업 평가가 필요하게 된다
Timely 적시에
- 테스트는 적시에 작성해야 한다

결론

공지사항

최근에 올라온 글

최근에 달린 댓글

링크

글 보관함