테스트 커버리지를 70% 이상 유지하면서 느낀점

2023. 3. 21. 19:44·프로그래밍/프로젝트

굿즈 포유 프로젝트를 진행하면서, 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
'프로그래밍/프로젝트' 카테고리의 다른 글
  • SQL Injection
  • Builder 패턴?
  • 도커 컴포즈 사용 시 DB 초기화 문제 해결 과정
  • 캐싱은 언제 적용하는게 좋을까?
황심지
황심지
  • 황심지
    꾸준함이 진리다
    황심지
  • 전체
    오늘
    어제
    • 분류 전체보기 (51)
      • 프로그래밍 (12)
        • 운영체제 (0)
        • Spring (4)
        • Java (10)
        • SQL (0)
        • HTTP (2)
        • 회고 (2)
        • Network (0)
        • 프로젝트 (12)
        • Infra (2)
        • 데이터베이스 (3)
        • TIL (1)
        • 파이썬 (2)
      • 운동 (0)
        • 거인화 루틴 일지 (0)
        • 과부하 훈련 일지 (0)
        • 운동 관련 이모저모 (0)
  • 블로그 메뉴

    • 홈
    • 방명록
    • 글쓰기
  • 링크

  • 공지사항

  • 인기 글

  • 태그

    레디스 세션
    세션
    배포 방식
    1년회고록
    한번에끝내는코딩테스트369Java편초격차패키지Online
    쿼리 성능
    position argument
    개인성장
    에프랩 후기 자바 백엔드 부트캠프
    직장인인강
    CAP Theorem
    CAP 이론
    django orm
    패캠챌린지
    에프랩 후기 자바 백엔드
    2023년회고
    페이징 최적화
    직장인자기계발
    chatops
    그런 RESTAPI로 괜찮은가?
    webflux
    python
    에프랩 후기
    Java
    패스트캠퍼스
    F-Lab 후기
    대용량 트래픽
    spring
    개인회고록
    패스트캠퍼스후기
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.3
황심지
테스트 커버리지를 70% 이상 유지하면서 느낀점
상단으로

티스토리툴바