이번 주는 무엇을 했나?
-
코드숨 강의에서 테스트 코드를 작성하는 법을 배웠다.
junit5를 사용해 정말 간단한 테스트 코드를 작성하는 법을 알고 있었지만 실제 스프링 애플리케이션을 테스트 하는 방법은 이번에 처음 해보았다.Mocito를 이용한 가짜 객체(정확히는 테스트 더블 이라고 한다. 종립님 블로그의 테스트 관련 용어를 참고했다.)를 만드는 방법이랑 스프링 환경에서 테스트하는 다양한 방법 등 여러가지를 배웠다.
과제를 가장 많이 생각했던거는 무엇을 테스트 해야하지 였고 테스트 더블은 언제 사용 해야는거야 라는 생각을 많이했다. 현재는 어느 정도 이거에 대해서 정리가 된거 같다.
그리고 테스트 코드를 작성하면서 느낀점인데 계층형(이것 역시 종립님의 JUnit5로 계층 구조의 테스트 코드 작성하기를 참고 했다. 정말 좋다!)으로 테스트를 잘 작성했을 경우 이 코드를 보는 미래의 나 혹은 다른 사람들이 볼 경우 어떤 코드인지 파악할 수 있는 문서가 될 수 있겠다는 생각을 했다.
반대로 말하자면 기능을 변경했는데 테스트 코드를 관리를 안하거나 테스트 코드를 설계와 무관하게 작성하면 오히려 없는것만 못하는 신뢰할 수 없는 문서가 될거 같다는 생각을 했다. -
자바와 JUnit을 활용한 실용주의 단위 테스트을 읽었다
테스트 코드에 대한 인사이트를 얻고 싶어서 구매를 했었다. 사실 테스트 주도 개발과 이 책에 대해서 무엇을 볼까 고민을 했지만 왠지 테스트 주도 개발책이 내가 이해하기 어려울거 같아서 좀 더 쉬울거 같은 이 책을 구매했다. 번역에 대해 안좋은 평이 있어서 고민을 했지만 결국 질렀다.
중간까지 읽었지만 번역이 안 좋다는 평을 들어서인지 아니면 내가 이해력이 딸리는건지 공감이 안되거나 이해가 되지 않은 부분이 많았다. 결국 스트레스만 받아서 결국 중간에 덮어 버렸다.
하지만 그 중에 얻은게 하나 있는데 좋은 유닛 테스트의 FIRST 원칙이라 해서 소개한 내용이 있다. 책의 내용을 한번 정리를 해봤다!- Fast
빨라야 한다. 단위 테스트의 가장 큰 장점은 빠른 피드백이다 데이터베이스 호출, 파일 네트워크 호출 등 처럼 외부 자원을 다루는 코드처럼 느린 것에 의존하지 마라 - Independent
독립적이여한다. 각 테스트는 독립적이게 수행되어야 하며 다른 테스트 코드에 영향에 주게 테스트를 작성하면 안된다. - Repeatable
반복 가능해야 한다. 테스트는 실행할 때마다 결과가 같아야한다. 직접 통제할 수 없는 외부 환경에 있는 항목들(랜덤 값, 시간과 관련된 함수, 네트워크 호출등과 같은 통제할 수 없는 것)과 격리시켜야 한다. 각 테스트는 항상 동일한 결과를 만들어 내야 한다. - Self-validating
스스로 검증이 가능해야한다. 각 테스트의 결과를System.out.println()같은 함수를 이용해 주관적으로 테스트하지 마라 테스트 결과는 성공 아님 실패 로만 결과를 나타내 자체적으로 검증되어야 한다. - Timely
적시에 사용 해야한다. 단위 테스트로 코드를 검증하는 것을 미룰수록 양치를 안하면 생기는 치석처럼 충치(결함)가 쌓이게 되고 코드가 커질 수록 테스트 코드를 작성하기 힘들것이다. 새로운 코드를 작성하는 즉시 테스트를 작성해라
- Fast
- 무엇을 테스트할 것인가? 어떻게 테스트할 것인가? 라는 컨퍼런스 영상을 봤다
이번 주 과제를 하면서 내가 고민했던 부분을 해결하는데 정말 많이 도움이 되었고 많은 인사이트를 얻을 수 있었다.
구현을 테스트하지 말고 설계(요구 사항)을 테스트 하라고 하셨다. 사실 이부분에 대해서는 윤석님 한테도 피드백을 받았었다.
결국에는 테스트를 작성할 때 설계(요구사항)을 명확히 알아야 하고 테스트를 읽는 사람은 미래의 나 혹은 다른 사람에게 어떤 요구 사항이 있는지 명확하게 설명 할 수 있어야 좋은 테스트라고 생각한다. (즉 사용자 입장에서 생각하자)
무분별한 테스트 더블을 남용하지 말라고 하셨다. 테스트 더블을 무분별하게 사용하면 설계가 아닌 구현 테스트로 빠지게 될 수 있다고 하셨다. 데이트베이스, 랜덤 함수, 외부 네트워크 자원을 사용하는 통제할 수 없는 영역을 테스트 더블로 처리 하라고 하셨다.
그리고 유닛 테스트에서 스프링 컨텍스트를 활용하는 테스트를 지양하라고 하셨다. 위에 FIRST 원칙에서 설명한것 처럼 테스트는 빠른 피드백이 장점인데 스프링 컨텍스트는 굉장히 느리니까 왠만하면 사용하지 말라고 하셨다 특히@SpringBootTest얘 생으로 사용하지 말자 모든 빈 다 긁어 온다.
또MockMvcTest같이 엔드포인트 테스트를 할 때에는 요청 스팩에 따른 응답 스팩만 검증 하는게 정신 건강에 이롭다고 하셨다.
이거 말고도 굉장히 많은 팁을 전수 해주셨는데 하나 같이 정말 좋은 내용들이 었고 처음 테스트하는 나한테는 많은 도움이 되었다.
이번 주를 마치며
이번 주는 굉장히 테스트 코드를 작성하는 것을 배우면서 고통 받았었고 하지만 고통 받은 만큼 성장했다고 느껴지는 주 였다.
다음 주에도 아마도 과제를 하면서 테스트 코드에 익숙해지는데 시간을 쏟아 부을거 같다.
테스트 코드에 대해 느끼는건데 정말 유용하고 좋은 도구는 확실한거 같다. 위에 말한것 처럼 관리를 하지 않거나 이해할 수 없게 테스트 코드를 작성하면 오히려 헷갈리게 해서 업무 효율성을 떨어뜨릴 수 있다고 생각한다. 평소에 테스트 코드를 작성하는 습관을 들여 적시에 사용 할 수 있도록 갈고 닦아야겠다.
