Step3 - 인수 테스트와 리팩터링

[sunga08]

안녕하세요!

3단계를 하면서는 이렇게 하는게 맞는가에 대한 생각을 많이 하게 됐던것 같습니다...
리팩토링 후에 테스트를 보충하기 보다 삭제를 많이 했는데, 대표적으로 Request DTO+validation이나 Enum 도입으로 Spring이 자동으로 검증해주게 되어서 잘못된 요청값으로 보내는 경우에 대한 테스트는 삭제를 했습니다. 인수테스트가 리팩토링시 안전망 역할을 해주는건데 오히려 테스트를 없애게 되니까 이게 맞나 싶더라구요,,
그리고 기능 보완은 기존 정책을 벗어나지 않는 선에서 하려고 하다 보니 파라미터 값 추가 검증이나 범위 지정 정도만 하게 되었는데, 기존 정책 외에 새로운 기능 추가를 해야 했던건지 살짝 헷갈리기도 했습니다...
제대로 된 방향으로 요구사항을 수행한게 맞을지 싶네요...ㅎㅎ;

그럼 피드백 부탁드리겠습니다..! 감사합니다:)

[boorownie]

3단계 요구사항 수행하시느라 고생 많으셨습니다!

미션 수행 방향에 대해 질문을 주셔서 그 방향으로 코드 리뷰를 했는데요,
지금도 물론 잘 해주셨는데 아래와 같은 방향으로 한번 더 경험해보시면 어떨까 제안드려요.
핵심은 새로운 기능 구현 시 기준 스펙이 변경되는 경우가 있는데
이 때 무작정 개선하기 보다는 조금 더 안정적인 방법으로 진행하는데 있습니다!

1. 신규 기능을 정의하고 설계하기
2. 신규 기능은 기존 스펙을 변경하는 부분을 포함하고 있음
3. 바로 기존 스펙을 변경하지 않고 기존 스펙을 검증하는 테스트를 보완하면서 진행
4. 이 때 기존 테스트를 바로 수정하지 않고 비슷한 테스트를 새로 만들기
5. 이렇게 한 다음 신규 기능을 검증하는 테스트를 만들고 기존 기능의 새로운 스펙을 검증하는 테스트를 구축
6. 그러고 신규 기능을 구현을 완성하면 위 두 테스트는 성공하고 기존 테스트는 실패함
7. 그렇게 성공적으로 기능 구현을 끝내면 기존 테스트는 제거
8. 만약 신규 기능을 구현하다가 꼬이거나 실패할 경우 다시 코드를 돌리는데 이 때 기존 테스트로 기존 기능이 유효한지 보호하기

이게 점진적으로 코드를 보호하는 테스트를 구축하는 방법인데
새로운 도메인이라던지 조금 더 공격적으로 신규 기능을 설계하고 진행해보아도 좋을 것 같습니다!

[boorownie]

리팩토링 후에 테스트를 보충하기 보다 삭제를 많이 했는데, 대표적으로 Request DTO+validation이나 Enum 도입으로 Spring이 자동으로 검증해주게 되어서 잘못된 요청값으로 보내는 경우에 대한 테스트는 삭제를 했습니다. 인수테스트가 리팩토링시 안전망 역할을 해주는건데 오히려 테스트를 없애게 되니까 이게 맞나 싶더라구요,,

인수 테스트는 아시다시피 많은 리소스가 필요한 테스트 입니다. 단순히 동작하는데 오랜 시간이 걸리는 것 외에도 개발자가 테스트를 구축하고 유지보수하는데도 상당한 리소스가 필요하죠.
따라서 인수 테스트는 반드시 필요한 부분으로 한정해야합니다.

지금 이 과정에서 성아님께서 경험하신 부분은 내가 정말로 필요하다고 생각하던 부분을 검증할 필요가 있었는가? 에 대한 고민으로 이어질 수 있습니다.
이어서 인수 테스트는 어떤 부분을 검증하는게 효과적이고 그 외 부분은 어느 테스트의 계층(통합? 단위?)에서 진행하는게 좋을지도 함께 고민할 수 있습니다!

[boorownie]

그리고 기능 보완은 기존 정책을 벗어나지 않는 선에서 하려고 하다 보니 파라미터 값 추가 검증이나 범위 지정 정도만 하게 되었는데, 기존 정책 외에 새로운 기능 추가를 해야 했던건지 살짝 헷갈리기도 했습니다...
제대로 된 방향으로 요구사항을 수행한게 맞을지 싶네요...ㅎㅎ;

사실 기존 기능 보완을 포함하여 완전히 새로운 신규 도메인으로 기능을 구현하는 것 까지도 기대해볼 수 있는데요,
이 요구사항의 목적은 새로운 기능 개선을 하면서도 기존 기능이 잘 보호되는지를 경험하기 위함입니다.

여기서 중요한 점은 스펙이 변경되면서 기존 기능이 변경되고 그러면서 테스트도 변경이 필요한 상황이 발생한다는점입니다.
이 때 새로운 기능을 기준으로 기능을 수정하면 기존에 만들어둔 테스트가 불필요하게 됩니다.

이럴 때 어떻게 접근해야할까요?
새로운 기능 구현으로 인해 기존 기능이 영향을 받는다면 기존 기능의 영향받는 부분의 테스트 부터 만들어주어야합니다.
영향을 안 받는다면 기존 테스트 그대로 효과가 있겠지만 기존 기능이 달라지는 부분이 있다면 달라진 스펙에 맞는 테스트가 필요합니다.

이 때 중요한 방법은 기존 테스트를 수정해서는 안된다는 점 입니다.
기존 테스트는 그대로두고 기존 기능의 새로운 스펙이 반영된 새로운 테스트를 구축해야합니다.
그런 다음 기존 기능의 새로운 스펙을 반영한 테스트가 정상적으로 동작하여 기존 테스트가 필요없어지면 그 때 제거해줍니다.

테스트의 보호속에서 점진적인 기능 개선을 할 때는 느리지만 천천히 갈 필요가 있습니다!

[boorownie]

테스트에서 직접 dto를 활용해주셨군요 👍

테스트에서 가급적이면 프로덕션의 코드를 사용하지 않게 하는 이유는
프로덕션의 변경 시 테스트에서 영향을 받는 것을 최소화 하기 위해서입니다만
dto까지 테스트에서 사용하는 용도로 따로 지정해주면 일을 2번해야하니 매우 번거롭습니다.

그래서 저는 dto 클래스 정도는 사용하는 편인데요,
이론적으로 효과적인 테스트를 구축하는 것 만큼 중요한게 개발자들이 테스트를 유지보수하고 관리할 때 얼마나 효율적인가 인거 같습니다!