11, 12일차 TIL 단위 테스트

DAY 11, 12

오늘의 책 읽기: 9장. 단위 테스트 까지

🤓 책에서 기억하고 싶은 내용

TDD 법칙 3가지
1. 실패하는 단위 테스트를 작성할때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 테스트를 작성한다.

 

자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다.
테스트는 유연성, 유지보수성, 재사용성을 제공하는 버팀목이다.

 

테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.
테스트 코드가 지저분할수록 실제 코드도 지저분해진다.

 

BUILD-OPERATE-CHECK패천이 위와 같은 테스트 구조에 적합하다.
각 테스트는 명확히 세 부분으로 나눠진다. 첫 부분은 테스트 자료를 만든다. 두 번째 부분은 테스트 자료를 조작하며, 세 번쨰 부분은 조작한 결과가 올바른지 확인한다.

 

테스트 코드는 단순하고, 간결하고, 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다.

 

JUnit으로 테스트 코드를 짤 때는 함수마다 assert 문을 하나만 사용하면
결론이 하나라서 코드를 이해하기 쉽고 빠르다.

 

assert문을 여러개라는 이유로 테스트 코드를 분리하면 중복되는 코드가 많아진다.

 

assert문이 여럿이라는 사실이 문제가 아니다. 한 테스트 함수에서 여러 개념을 테스트한다는 사실이 문제다. 그러므로 가장 좋은 규칙은 "개념 당 assert문 수를 최소로 줄여라", "테스트 함수 하나는 개념 하나만 테스트하라"라 하겠다.

 

F.I.R.S.T
Fast: 테스트는 빨라야 한다.
Independent: 각 테스트는 서로 의존하면 안 된다.
Repeatable: 테스트는 어떤 환경에서도 반복 가능해야 한다.
Self-Validating: 테스트는 부울값으로 결과를 내야 한다.
Timely: 테스트는 적시에 작성해야 한다.

 

🥰 오늘의 소감

Node.js로 주로 개발을 하면서 가장 고민 되는 부분이 테스트였다. 초반에 Node.js 공부를 할때 테스트 부분을 건너뛰었고 결국 테스트를 하지 않고 개발을 진행하는 것에 익숙해져서 결국 지금하는 프로젝트에서도 테스트 코드를 짜지 않는다... 최대한 빨리 공부를 시작하고 습관을 들여야겠다..

 

🤔 궁금한 내용

도메인 특화 언어(DSL): 특정한 도메인을 적용하는데 특화된 컴퓨터 언어이다. 이는 어느 도메인에서나 적용 가능한 범용 언어(General-purpose language)와는 반대되는 개념이다.