안녕 하세요~~

실무에서 테스트를 어떻게 작성하는가에 대한 이야기를 하려면 강의 하나를 더 만들어야 할 것 같긴한데요...

간단하게만 답변을 드리자면, 스프링 프로젝트를 이끌어온 유겐 횔러처럼 스마트하게 테스트를 만들려고 합니다. 모든 걸 다 테스트 하는지, 어떤 건 어떤식으로 테스트하는지 등의 대한 절대적인 기준이 없고 그때그때 이건 어떻게 테스트를 만드는 게 좋을지 생각하면서 만듭니다. 물론 팀으로 개발하는 경우는 팀의 테스트 작성 능력에 따라서 나름의 가이드를 만들기는 하지만요.

도메인이나 비즈니스 로직이 있는 코드는 최대한 단위 테스트로 만듭니다. 그 중에서 돈이 관련이 되는 코드는 무조건 TDD로 만듭니다. 그 외에 어떻게 발전시킬지 좀 막연한 코드도 TDD로 개발합니다. TDD가 아니더라도 코드를 작성한 후에 최대한 빠르게 테스트를 만들려고 합니다. 대부분 바로 이어서 만듭니다. 어떻게 만들어야 할지 너무 뻔한코드라면 테스트를 만드느라 뒤로 미루지 않습니다. 극단적인 예지만 실제로 많이 본 예를 들자면 new ArrayList()하면 null이 아닌 오브젝트가 만들어지는가를 테스트를 먼저 만들면서 작성하지 않습니다.

API 서비스라면 API 테스트는 DB까지 참여시키는 방식으로 해서 만듭니다. 주요 API 기능은 빠짐없이 테스트를 만듭니다. 물론 DB는 롤백 테스트를 이용해서 고립된 테스트가 가능하게 만듭니다. 서버 사이드 뷰는 테스트하지 않습니다. 로직이 있다면 컴포넌트로 빼서 그걸 테스트하고, 순수 템플릿은 테스트하지 않습니다. 한 때는 그것도 해보려고 했습니다만. 아무튼, 그건 웹 UI 테스트쪽으로 넘깁니다.

고전파/런던파, 시카고-디트로이트학파/런던학파라는 식의 구분을 싫어하고 별 의미없다고 생각합니다. 구체적으로 어떤 경우에 어떤 방식을 택하겠는가, 어떻게 접근하겠는가 등의 방식으로 이야기해야 한다고 봅니다. 어느 쪽이든 극단적인 주장은 싫어합니다.

테스트는 빠르게 효율적으로 잘 만들 수 있는 게 중요합니다. 애플리케이션 코드보다 더 능숙하게 잘 만들어야 합니다. 안그러면.. 결국 일정에 쫒겨서 테스트를 안 만들게 되거든요. 그러려면 꾸준히 다양한 테스트 기법을 사용하며 평가해보며 자신만의 테스트 작성 전략을 만들어보고 필요한 도구를 만들면서 연습해야 합니다. 더 빠르게 더 좋은 테스트를 작성하는 훈련을 해보세요.