코드숨 강의에서 테스트 코드를 작성하는 법을 배웠다.
junit5
를 사용해 정말 간단한 테스트 코드를 작성하는 법을 알고 있었지만 실제 스프링 애플리케이션을 테스트 하는 방법은 이번에 처음 해보았다. Mocito
를 이용한 가짜 객체(정확히는 테스트 더블 이라고 한다. 종립님 블로그의 테스트 관련 용어를 참고했다.)를 만드는 방법이랑 스프링 환경에서 테스트하는 다양한 방법 등 여러가지를 배웠다.
과제를 가장 많이 생각했던거는 무엇을 테스트 해야하지 였고 테스트 더블은 언제 사용 해야는거야 라는 생각을 많이했다. 현재는 어느 정도 이거에 대해서 정리가 된거 같다.
그리고 테스트 코드를 작성하면서 느낀점인데 계층형(이것 역시 종립님의 JUnit5로 계층 구조의 테스트 코드 작성하기를 참고 했다. 정말 좋다!)으로 테스트를 잘 작성했을 경우 이 코드를 보는 미래의 나 혹은 다른 사람들이 볼 경우 어떤 코드인지 파악할 수 있는 문서가 될 수 있겠다는 생각을 했다.
반대로 말하자면 기능을 변경했는데 테스트 코드를 관리를 안하거나 테스트 코드를 설계와 무관하게 작성하면 오히려 없는것만 못하는 신뢰할 수 없는 문서가 될거 같다는 생각을 했다.
자바와 JUnit을 활용한 실용주의 단위 테스트을 읽었다
테스트 코드에 대한 인사이트를 얻고 싶어서 구매를 했었다. 사실 테스트 주도 개발과 이 책에 대해서 무엇을 볼까 고민을 했지만 왠지 테스트 주도 개발책이 내가 이해하기 어려울거 같아서 좀 더 쉬울거 같은 이 책을 구매했다. 번역에 대해 안좋은 평이 있어서 고민을 했지만 결국 질렀다.
중간까지 읽었지만 번역이 안 좋다는 평을 들어서인지 아니면 내가 이해력이 딸리는건지 공감이 안되거나 이해가 되지 않은 부분이 많았다. 결국 스트레스만 받아서 결국 중간에 덮어 버렸다.
하지만 그 중에 얻은게 하나 있는데 좋은 유닛 테스트의 FIRST 원칙이라 해서 소개한 내용이 있다. 책의 내용을 한번 정리를 해봤다!
System.out.println()
같은 함수를 이용해 주관적으로 테스트하지 마라 테스트 결과는 성공 아님 실패 로만 결과를 나타내 자체적으로 검증되어야 한다.@SpringBootTest
얘 생으로 사용하지 말자 모든 빈 다 긁어 온다.MockMvcTest
같이 엔드포인트 테스트를 할 때에는 요청 스팩에 따른 응답 스팩만 검증 하는게 정신 건강에 이롭다고 하셨다.이번 주는 굉장히 테스트 코드를 작성하는 것을 배우면서 고통 받았었고 하지만 고통 받은 만큼 성장했다고 느껴지는 주 였다.
다음 주에도 아마도 과제를 하면서 테스트 코드에 익숙해지는데 시간을 쏟아 부을거 같다.
테스트 코드에 대해 느끼는건데 정말 유용하고 좋은 도구는 확실한거 같다. 위에 말한것 처럼 관리를 하지 않거나 이해할 수 없게 테스트 코드를 작성하면 오히려 헷갈리게 해서 업무 효율성을 떨어뜨릴 수 있다고 생각한다. 평소에 테스트 코드를 작성하는 습관을 들여 적시에 사용 할 수 있도록 갈고 닦아야겠다.