굿즈 포유 프로젝트를 진행하면서, Jacoco와 Github Action을 통해 테스트 커버리지가 70%를 넘기지 못하면 빌드를 실패하게 설정했습니다. 이 과정에서 70% 이상의 테스트 커버리지를 유지하면서 느낀 점에 대해 본 포스팅을 통해 얘기해 보겠습니다.(작성한 테스트 코드는 https://github.com/f-lab-edu/Goods-For-You 를 통해 보실 수 있습니다😊)
처음 테스트 코드를 작성할 때는 커버리지를 70% 이상 유지하기 위해, 모든 클래스의 테스트 코드를 작성했습니다.
위 사진과 같이 모든 클래스에 대해 테스트 코드를 작성하면서, 느낀 점은 다음과 같습니다.
첫 번째. 테스트 코드도 프로덕션 코드와 동일한 수준으로 주의를 기울여 작성해야 한다는 것이었습니다.
- 명확하고 간결한 테스트 사례를 작성하기 위해, Describe-Context-it 방식의 패턴을 테스트 코드에 적용해, 테스트 코드의 가독성을 높였습니다.(해당 방식에 대해서는 https://johngrib.github.io/wiki/junit5-nested/ 본 링크를 참고했습니다)
두 번째. 테스트 코드는 구현 세부 사항보다는 시스템 동작에 중점을 두고 작성해야 한다는 것입니다.
- 처음 테스트 코드를 작성할 때, 특히 애플리케이션의 비즈니스 로직을 담고 있는 객체를 테스트할 때, 서비스 객체에 의존하는 많은 객체들을 직접 의존성 주입해 줬습니다.
class NewUserManagementTest {
UserValidator validator;
NewUserCreator creator;
UserFinder finder;
UserManagement userManagement;
UserRepositoryPort userRepositoryPort;
List<NewUserPolicy> validityPolicyList;
List<LoginUserPolicy> loginUserPolicyList;
TokenGenerator tokenGenerator;
AuthService authService;
MockHttpSession session;
LoginUserCommand loginuserCommand;
@BeforeEach
void setUp() {
userRepositoryPort = new MemoryUserRepositoryAdapter();
creator = new NewUserCreator(userRepositoryPort);
finder = new NewUserFinder(userRepositoryPort);
validityPolicyList = List.of(new NewUserEmailPolicy(finder), new NewUserNamePolicy(finder),
new NewUserPasswordPolicy());
loginUserPolicyList = List.of(new LoginUserEmailPolicy(finder));
validator = new NewUserValidator(validityPolicyList, loginUserPolicyList);
tokenGenerator = new UUIDTokenGenerator();
session = new MockHttpSession();
authService = new SessionAuthService(session);
userManagement = new NewUserManagement(creator, validator, tokenGenerator, authService);
loginuserCommand = new LoginUserCommand("wook@test.com", "123123123");
}
위 코드는 앞서 말한 의존성을 직접 주입해 준 테스트 코드의 일부입니다. 이렇게 모든 의존성을 주입해 주게 되니, 구현 세부 사항에 집중한 테스트 코드를 작성하는 방향으로 흘러가게 되었습니다. 해당 테스트 코드를 리팩토링 한다면 NewUserManagement에서 기대되는 동작에 집중해 테스트를 작성하기 위해, 테스트 더블 기법을 이용해 리팩토링 할 수 있을 것 같습니다.( 테스트 더블은 테스트하려는 코드를 주변 환경에서 분리하게 도와주는 객체 또는 테스트 작성 시 테스트 대상 코드와 상호작용 하는 객체입니다)
마지막으로 70% 이상의 테스트 커버리지를 유지하면서 느낀 점은 테스트 커버리지를 높게 유지하는 것이 일회성 작업이 아닌 지속적인 노력이라는 것을 배웠습니다. 새로운 기능이 추가되고 버그가 수정됨에 따라 이러한 코드의 변경 사항을 반영하도록 테스트 코드를 지속적으로 작성해야 한다는 것을 깨달았습니다.
결론적으로 70% 이상의 테스트 커버리지를 유지하면서, 테스트 코드를 작성함으로써 시간 낭비가 아닌 소프트웨어의 품질을 보장하고 더 향상할 수 있는 중요한 부분이라고 생각이 들었습니다. 테스트 커버리지 70% 이상을 유지하는 경험을 통해 테스트 코드도 프로덕션 코드만큼 주의를 기울여 다루어야 하고, 테스트 코드 작성 시 구현 세부 사항보다는 테스트하고자 하는 동작에 초점을 맞춰 테스트를 작성해야 하며, 테스트 코드의 유지관리 및 확장성을 생각하며 코드를 작성해야 하며, 작성한 테스트 코드도 프로덕션 코드처럼 리팩토링이 필요하다는 것을 깨달았습니다.
'프로그래밍 > 프로젝트' 카테고리의 다른 글
SQL Injection (0) | 2023.04.05 |
---|---|
Builder 패턴? (0) | 2023.04.05 |
도커 컴포즈 사용 시 DB 초기화 문제 해결 과정 (0) | 2023.03.18 |
캐싱은 언제 적용하는게 좋을까? (2) | 2023.03.07 |
CAP 이론을 바탕으로 NoSQL 을 적용 할 만한 포인트 고려 (0) | 2023.03.02 |