개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
테스트 코드는 지속적으로 깨끗하게 관리하자
테스트 코드는 표현력을 높이고 간결하게 정리하자
테스트 API를 구현해 도메인 특화 언어(Domain Specific Language, DSL)를 만들자
TIL (Today I Learned) 날짜
2022.03.05 ~ 2022.03.06
오늘 읽은 범위
9장. 단위 테스트
먼저 읽은 후
8장. 경계
내용 정리는 9장의 내용
책에서 기억하고 싶은 내용을 써보세요.
실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
=> 위 세가지 규칙을 따르면 개발과 테스트가 대략 30초 추기로 묶인다.
테스트코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다.
개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다.
시스템 이쪽을 수정해도 저쪽이 안전하다는 사실을 검증하지 못한다.
결함률이 높아지기 시작한다.
의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다.
변경하면 득보다 해가크다 생각해 더 이상 코드를 정리하지 않는다.
코드가 망가지기 시작한다
코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다.
코드의 변경이 두렵지 않다 -> 코드의 변경이 쉬워진다
가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다.
테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.
테스트 코드는 본론에 돌입해 진짜 필요한 자료 유형과 함수만 사용한다.
시스템 조작 API를 사용하는 대신 API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하므로 테스트 코드를 짜기도 읽기도 쉬워진다.
이렇게 구현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 된다.
테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어다.
실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다.
대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다.
"개념당 assert 문 수를 최소로 줄여라"
"테스트 함수마다 한 개념만 테스트하라"
이것저것 잡다가 개념을 연속으로 테스트하는 긴 함수는 피한다.
Fast(빠르게) : 테스트는 빨라야 한다. 테스트는 빨리 돌아야 한다는 말
Independent(독립적으로) : 각 테스트는 서로 의존하면 안 된다. 한 테스트가 다음 테스트가 실행될 환겨을 준비해서는 안 된다.
Repeatable(반복적으로) : 테스트는 어떤 환경에서도 반복 가능해야 한다.
Self-Validating(자가검증하는) : 테스트는 bool값으로 결과를 내야 한다.
Timely(적시에) : 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
테스트 주도 개발을 해보려고 했다가 테스트 환경 구성부터 막혀서 결국엔 꼭 테스트 자동화 환경을 구축해서 개발을 해야해? 빨리 잘 돌아가게만 만들어도 되잖아? 테스트 자동화 환경 구축하고 하느라 개발할 시간 다 잡아먹겠다! 라는 생각에 시도만 찔끔 하다가 나 혼자만의 테스트 방식, 사실상 테스트라고 말하기도 민망한 수준의 테스트를 돌리고 잘 되네! 하고 만족했던 적이 생각나는 장이다.
일정이 촉박하니까, 일단 잘 동작하니까 라는 생각으로 테스트를 외면하면 결국 그 부메랑은 레거시 코드가 되어 나에게 돌아왔던 것 까지도.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
BUILD-OPERATE-CHECK 패턴
given-when-then 관례
오늘 읽은 다른사람의 TIL
k.j.choi 님의 TIL https://kjchoi.co.kr/13
hamzzisu 님의 TIL https://blog.naver.com/jiing_ee/222665231016