테스트 코드 꿀팁🎉

SI 때 혹은 과거의 경험

• 테스트는 모두 사람이 하는 것이었고, 한번의 테스트는 상당한 노동력을 필요로 했다.
• SI에서는 전용 테스트 팀이 따로 있었고, 인수인계 전에 인수테스트라는 것을 진행해서 기능적인 테스트를 꼼꼼히 했었음.

그러다가 블러온 테스트의 바람

• 로직이 대부분 쿼리에 있는 mybatis에서는 테스트하기가 상당히 까다로웠음.
• 그 후 시간이 지나 JPA를 하게 되고, 쿼리가 아닌 자바 코드에 로직이 많이 담기게 된다.
  • 유지보수성의 극적인 향상(쿼리로는 다형성이나 디자인패턴 전략 등을 하기 어렵거나 불가능)
  • 자바코드에 담긴 로직은 테스트하기 쿼리에 담긴 로직에 비해 상대적으로 편리함.

---

TDD & 실무

• 처음 공부해보고 도입하려고 해보았으나, 클래스의 구성이나 프로그램 구조가 잡히지 않은 상태에서는 어려웠다.
• 여러가지로 공부해보고 실무나 주변을 본 결과 완벽한 의미의 TDD(일단 테스트 먼저 짜고 코드를 만드는 것)은 어렵다.

---

테스트를 잘 하기 위한 기반

• 클래스나 메서드가 SRP를 잘 지키고, 크기가 적절히 작아야 한다.
  • 그래야 테스트를 집중력 있게 만들 수 있고 한 메서드에 너무 많은 테스트를 수행하지 않아도 된다.
  • 이게 테스트를 하는 것의 장점이 되기도 한다. (테스트를 하면 먼저 자연스럽게 역할이 확인되면서 쪼개짐.
• 적절한 Mocking을 통한 격리성 확보
  • 단위 테스트가 만능은 아니지만, 위의 SRP처럼 해당 메서드의 역할을 정확히 테스트 하려면 주변 조건을 적절히 통제해야 한다.
• 당연히 잘 돌겠지라는 생각말고 꼼꼼히 테스트 && 너무 과도하게 많은 테스트와 코드량이 생기지 않도록 적절히 끊기
  • 테스트 코드도 코드 리뷰 시에 적절한 테스트를 하는지 확인 필요
• 테스트 코드 개선을 위한 노력
  • 테스트코드도 리팩토링 필요
  • 테스트코드의 기법들도 지속적인 고민 필요(통합테스트 등)

---

결론

• *테스트 코드는 -> 코드의 품질도 높여주며 추후에 코드를 작성 시 시간을 아끼게 해준다.
• 나도 테스트 코드는 본인이 짠 코드를 의심하니까 짜는거겠지 라고 생각했었던 시절이 있었다.
• 하지만 코드는 혼자만 보는것도 아니며, 내가 그 코드를 기억할거라는 보장도 없다.
• 테스트 코드로 검증을 하여 시간을 아끼고 코드의 품질을 높여줄 수 있는 최고의 수단이다.
  이 글은 옵시디안에서 작성되었습니다.