패스트캠퍼스 챌린지 16일차

1. 테스트를 잘 하는 방법

기존의 테스트 방식

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

그 후에 불어온 테스트의 바람

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

TDD & 실무

• 클래스의 구성이나 프로그램 구조가 잡히지 않은 상태에서는 테스트를 먼저 짜는 것이 힘들다.
• 완벽한 의미의 TDD는 실현되기 어렵다.

테스트를 잘 하기 위한 기반

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

 

 

본 포스팅은 패스트 캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.
https://bit.ly/3FVdhDa

수강료 100% 환급 챌린지 | 패스트캠퍼스