개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
테스트 코드는 변경으로 가는 문턱을 낮춰줌으로써 유연성, 유지보수성, 재사용성을 제공한다.
그렇기 때문에 읽기 쉬운 깨끗한 테스트 코드를 유지하는 것은 매우 중요하다.
깨끗한 테스트 코드를 위해 책에서 제시한 FIRST 규칙을 명심하자.
TIL (Today I Learned) 날짜
2022.03.06
오늘 읽은 범위
9장. 단위 테스트
책에서 기억하고 싶은 내용을 써보세요.
문제는 실제 코드가 진화하면 테스트 코드도 변해야 한다는 데 있다. 그런데 테스트 코드가 지저분할수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다. 실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해, 실패하는 테스트 케이스를 점점 더 통과시키기 어려워진다. 그래서 테스트 코드는 계속해서 늘어나는 부담이 되버린다. - 156p
테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 이류 시민이 아니다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다. - 157p
테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 있으면 변경이 쉬워지기 때문이다.
따라서 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다. 테스트 코드가 지저분할수록 실제 코드도 지저분해진다. 결국 테스트 코드를 잃어버리고 실제 코드도 망가진다. - 157p
깨끗한 테스트 코드를 만들려면? 세 가지가 필요하다. 가독성, 가독성, 가독성. 어쩌면 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다. 테스트 코드에 서 가독성을 높이려면? 여느 코드와 마찬가지다. 명료성, 단순성, 풍부한 표현력이 필요하다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. - 158p
어쩌면 “테스트 함수마다 한 개념만 테스트하라”는 규칙이 더 낫겠다. 이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다. - 166p
테스트는 빨라야 한다. 테스트는 빨리 돌아야 한다는 말이다. 테스트가 느리면 자주 돌릴 엄두를 못 낸다. 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다. - 167p
각 테스트는 서로 의존하면 안 된다. - 167p
테스트는 어떤 환경에서도 반복 가능해야 한다. - 168p
테스트는 부울 값으로 결과를 내야 한다. 성공 아니면 실패다. - 168p
단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다. 어떤 실제 코드는 테스트하기 너무 어렵다고 판명날지 모른다. 테스트가 불가능하도록 실제 코드를 설계할지도 모른다. - 168p
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
이제껏 테스트 코드의 중요성을 너무 간과했던 것 같다는 생각이 들었다. 그리고 그런 나의 태도가 코드가 적절한 방향으로 변화해야 하는 것을 막은 장애물이 되지 않았을까하는 생각도 들었다.
규모가 큰 프로젝트일수록, 변화를 도모하기가 더욱 힘들어진다. 학교에서 다루는 작은 규모의 프로젝트면, 이전의 내가 그랬던 것처럼 처음부터 뜯어 고치는 방법도 가능할 것이다. 하지만 큰 규모의 프로젝트면 불가능한 일이며, 사용자와의 상호작용을 중요시하는 애자일 시대에서는 더군다나, 그 큰 규모의 프로젝트를 사용자의 요구에 맞게 계속 변화시켜야 한다. 이를 위해 깨끗한 코드를 작성해야 한다는 것을 앞부분에서 배웠다면, 이번 챕터에서는 깨끗한 테스트 코드를 작성하는 것도 그만큼 중요하다는 것을 알 수 있었다. 또한, 프로젝트가 더 유연해지기 위해 테스트하기 용이한 코드를 작성하는 것의 중요성도 알 수 있었다.
이전에, 프로젝트를 위해 책을 참고하면서, 기능의 구현 측면에만 신경쓰느라 단위 테스트 파트는 대충 넘겨 봤던 기억이 있다. 앞으로는, 절대 그러지 말아야지. 규모가 작은 프로젝트를 할 때도 항상 향후의 변화를 염두에 두며, 테스트를 신경쓰도록 노력해야겠다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
TDD(Test Driven Development) : 테스트 주도 개발. 테스트 코드 작성보다 개발 코드 작성이 선행되는 기존의 방식과 달리, 테스트 코드 작성이 선행되는 개발 방식. (참고 : http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/)
Build Operate Check Pattern : test는 build (test 시나리오를 준비하는 단계) - operate (test중인 object나 API에서 메서드를 실행해보는 단계) - check (실행된 메서드가 예상한 결과를 도출했는지 확인해보는 단계)를 거쳐 이루어져야 한다. (참고 : https://medium.com/swlh/usual-production-patterns-applied-to-integration-tests-50a941f0b04a)
DSL(Domain Specific Language) : 특정 영역을 타겟하고 있는 언어로, 특정 목적만 달성할 수 있는 언어 (참고 : https://lannstark.tistory.com/13)
Template Method Pattern : 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화하는 것으로, 전체적으로는 동일하나, 부분적으로 다른 구문이 많은 코드에서 중복을 피하기에 좋은 방법이다. (참고: https://gmlwjd9405.github.io/2018/07/13/template-method-pattern.html)
오늘 읽은 다른사람의 TIL
각종 테스트 방법에 대한 글을 공유해주신 것, 테스트에 관한 경험과 생각을 공유하신 부분이 좋았습니다.