이 포스트는 2021.12~2022.09 기간동안 벨로그에 작성한 글을 티스토리에 옮겨 적은 것입니다.
9장 단위 테스트
TDD 법칙 3가지
- 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
- 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
위 3가지 법칙을 따르면 개발과 테스트를 빠르게 수행할 수 있다.
단 이렇게하면 테스트 케이스가 너무 많이 나와서 관리가 힘들 수 있다.
깨끗한 테스트 코드 유지하기
지저분한 테스트 코드를 내놓느니 차라리 안하는게 낫다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸린다. 테스트 코드는 실제 코드 못지 않게 중요하다.
테스트는 유연성, 유지보수성, 재사용성을 제공한다.
코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. 테스트 케이스가 있으면 변경이 쉬워지기 때문이다. (문제 풀고 나서 답지가 있는 것과 같은 안도감인듯..)
깨끗한 테스트 코드
깨끗한 테스트 코드를 만들려면 가독성이 필요하다. 가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요하다. 잡다하고 세세하게 쓰기보다는 코드가 수행하는 기능을 빨리 이해할 수 있도록 진짜 필요한 자료 유형과 함수만 사용하자.
도메인에 특화된 테스트 언어
시스템 특화 api를 사용하는 대신 api 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하면 테스트 코드를 짜기도 읽기도 쉬워진다. 테스트 api를 구현에 도메인 특화 언어(DSL)을 만들면 테스트 코드 짜기가 쉬워진다.
이중표준
실제 환경과 테스트 환경은 요구사항이 판이하게 다르다.실제 환경에서는 안되지만 테스트 환경에는 문제 없는 방식이 있다. 그러니까... 실제 환경만큼 효율성에 목숨걸 필요가 없다. 성능보다는 가독성에 투자하자.
테스트 당 assert 하나
assert 문이 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽다. 함수 하나에 assert 하나만 들어갈 수 있도록 노력하자.
테스트 당 개념 하나
테스트 함수마다 한 개념만 테스트하라.
🔎assert란?
뒤의 조건이 True가 아니면 AssertError를 발생한다. 원하는 조건의 변수 값을 보증받을 때까지 assert로 테스트 할 수 있다.
F.I.R.S.T
깨끗한 코드는 다음 다섯가지 규칙을 따르는데, 각 규칙에서 첫 글자를 따오면 FIRST가 된다.
빠르게(FAST)
테스트는 빨리 돌아야 자주 돌려서 문제를 빨리 찾을 수 있다.
독립적으로(Independent)
각 테스트는 서로 의존하면 안된다. 테스트가 서로에 의존하면 우르르 실패하기 때문에 원인을 진단하기 어려워진다.
반복가능하게(Repeatable)
테스트는 어떤 환경에서도 반복 가능해야 한다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
자가검증하는(self-vaildating)
테스트는 성공 아니면 실패다. 통과 여부를 알려고 뭔가 읽게 만들어선 안된다.
적시에(Timely)
테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
댓글