테스트를 많이 하는 게 좋다고 하니까 많이 하고 싶은데 대부분의 상황이 테스트가 어려운 상황이 많다. 이미 테스트가 없는 코드에서 테스트를 하려고 하다 보면 설계 때문에 어려운 경우가 많다. 그래서 처음부터 TDD로 하는 게 좋은 것 같다. 코드 커버리지도 나중에 붙이려면 굉장히 고통이다. 하지만 처음부터 잘 적용시켜 놓으면 유지하는 것은 그렇게 어렵지 않다. 최근에 한 프로젝트에서 커버리지를 100%를 달성했는데, 달성하는 과정에서 github에서 coverage가 낮아진다면 머지가 안되는 기능을 만들기 위해 봇을 찾았었다. 커버리지 100%를 달성했더니 내 스스로 100%를 깨는 것을 싫어서 수동으로도 확인해서 100%를 맞추고 있다. 역시 첫 단추를 잘 끼우는 게 좋은 것 같다.
테스트를 많이 작성했는데 하나를 수정했더니 나머지가 와르르르 깨지는 경우가 있다는 분도 있었다. 아마 테스트를 먼저 작성하지 않아서 그렇다고 했다. 테스트를 작성하면서 테스트하기가 어렵다면 설계를 변경해야 하는 신호로 보는 게 좋다.
Private metohd
는 어떻게 테스트해야 하는지 궁금한 분도 있었다. Private method
를 테스트하려고 한다면 이것도 설계를 개선해야 할 신호로 보는 게 좋다고 했다. 대부분의 경우 SRP
원칙을 어기는 경우가 많을 것이고 설계를 개선하면 모두 테스트가 가능할 것이다.
인수 테스트의 작성을 어려워하시는 분들이 많았다. 인수 테스트 작성을 안 한다는 것은 무엇을 만들지 명확하지 않은 상태에서 만드는 것과 같다. 인수 테스트가 어려운 것은 코드 자체의 어려움도 있지만 명확히 무엇을 만들지 안정해서 그런 경우가 더 많다. 인수 테스트를 작성하면서 모호한 것들을 명확하게 만들어야 나중에 고생을 안 한다.
Value Object
의 사용을 많이 하는 게 좋다. 이 얘기를 하면서 객체지향에 대해서도 더 얘기했다.
자바스크립트로 직접 만들면서 배우는 - 자료구조와 알고리즘 강의 바로 가기
실습으로 마스터하는 OAuth 2.0: 기본부터 보안 위험까지 - OAuth 2.0 강의 바로 가기
기계인간 이종립, 소프트웨어 개발의 지혜 - Git 강의 바로 가기
코드숨에서 매주 스터디를 진행하고 있습니다. 메일을 등록하시면 새로운 스터디가 시작될 때 알려드릴게요!