인수 테스트, 테스트 Fixture에 대한 논의

[greeng00se]

다음 PR에 대한 논의가 길어져 옮겨봅니다!

[greeng00se]

후추의 질문

테스트가 전체적으로 깔끔해졌어요. 여러 픽스쳐가 생겼고, 통일성이 생겼네요. 당장 보기에 좋아보여요. 하지만 저는 살짝 걱정이 돼요. 두 가지 상황이 벌어질 수 있을 것 같아요.

리오와 제가 마음대로 테스트를 짜다가 시간이 지남에 따라 통일성이 떨어지게 된다.
리오와 제가 허브의 방식대로 테스트를 짜기 위해 노력하다가 전보다 많은 리소스(시간, 에너지 등)를 쓴다.
두 번째 리소스에 대한 부분은 손에 익지 않은 방식을 따라가면서 느낄 어색함 때문이에요. 테스트를 작성할 때마다 픽스쳐가 있는지, 이름은 무엇인지, 무엇을 인자로 넘겨야 하는지 등을 찾아봐야 할테고, 통일성을 위해 이전의 테스트를 확인해야 할 테니까요.

어떻게 하면 효율적으로 위 문제들을 해결할 수 있을까요?

허브의 답변

이 부분은 인수테스트를 하면서도 적용이 되는 문제고, 프로덕션 코드를 작성 하면서도 있을 수 있는 문제라고 생각합니다.

1번의 경우 사실 코드리뷰와 지속적인 리팩터링을 통해 충분히 해결할 수 있다고 생각합니다.
2번의 경우는 문제가 될 수도 있을 것 같아요.
이를 해결하기 위해 최대한 기존 코드와 일관성 있는 방식으로 테스트 코드에 Fixture를 적용하려고 노력했어요.
손에 익지 않은 방식을 사용함으로써 어색함이 있을 순 있지만, 기존의 코드를 읽는 시간 + 기존과 유사하게 테스트를 작성하거나, 일관성 없는 테스트를 작성하는 것 그리고 그 코드를 코드리뷰 하는데 드는 시간보다는 적게 들거라고 생각되어 저는 적절한 트레이드 오프라고 생각되는데 어떻게 생각하시나요?

또한 1, 2번을 해결하기 위해 추가적으로 테스트를 정리하면서 테스트 컨벤션을 작성해서 문서화하는 것도 좋은 방법이라고 생각되는데 추석이 끝나고 테스트에 대해 맞춰보는 시간을 가지고, 그 부분을 문서화하는건 어떻게 생각하시나요?

[Combi153]

• 트레이드 오프 라고 말한 지점이 정확히 무엇인지 이해가 안 됩니다! 어떤 선택에 대한 득과 실을 비교하신 건지 다시 설명해주실 수 있을까요?
• 문서화 좋습니다!
• 결국 우리만의 테스트 문화를 만들어야 한다는 생각이 들어요! 지금은 팀원 각자가 생각하는 테스트의 목표와 그 우선순위들이 다를 것 같아요. 예를 들어, 저는 테스트의 통일성과 신속성(개발자가 빠르고 편하게 작성할 수 있는 테스트)을 비교하면, 신속성에 더 큰 가치를 두어요. 그래서 테스트의 통일성이 깨지는 문제에 대해 코드리뷰와 지속적인 리팩터링을 통해 충분히 해결하는 방식이 리소스 낭비일수도 있겠다고 생각해요. 그러나 이것은 개인적인 차원이에요. 건설적인 토론을 바탕으로 팀 차원의 목표와 우선순위를 정하고, 건강한 테스트 문화를 형성합시다!

[greeng00se]

실: 손에 익지 않은 방식을 사용함으로써 어색함 -> 익숙해지는데 시간이 많이 드는 문제
득: 익숙해진다면 코드를 읽는 시간 단축, 일관성 있는 테스트 작성, 테스트 코드를 리뷰하며 드는 시간 단축이 예상됩니다.
특히 given 절에 있는 코드들을 일관성 있게 작성할 수 있다는 점이 장점이라고 생각해요. 기존의 경우 복사 붙여넣기로 진행되는 부분이 많았으니까요!

따라서 한 번 만들어두고, 익숙해진다면 후추가 생각하는 가치에 더욱 부합해질 수 있다는 생각이 드는데 어떻게 생각하시나요?

[Jaeyoung22]

한 명이 맡아서 테스트에 대한 리팩터링을 진행했고, 이 부분을 나머지 두명이 동의했다는 건 이후에 작성될 테스트에 대해서도 리팩터링을 맡은 사람의 논리적 흐름이나 사용하는 도구들에 대한 통일성을 지키겠다는 암묵적인 합의라고 생각합니다. 후추 생각은 어떠실까요?

[Combi153]

@Jaeyoung22 저는 암묵적 합의라고 생각하지는 않았습니다! PR 리뷰하면서 맞춰갈 부분이라고 생각했어요.
@greeng00se 감사합니다. 이해했습니다! 그러면 실을 줄일 수 있는 효율적인 방법을 논의합시다. 일단 테스트 코드에 대한 문서화!!

[greeng00se]

문서 초안은 일단 이번 주 주말 중으로 간단하게 작성해보겠습니다. Discussion에 링크 만들어둘테니 확인 부탁드립니다.

다음 링크에서 이번 Fixture 수정에 대한 부분 제가 초안을 작성할테니 의견 남겨주시면 감사하겠습니다!
#437

[greeng00se]

후추의 질문

현재 패키지 구조에서 Test 시 양방향 의존은 어쩔 수 없는 부분인 것 같습니다. 테스트의 주 목적은 프로덕션 코드에 대해 믿을 수 있는 검증을 하는 것이라 생각합니다. 이러한 검증을 위해서 Trip이 Post를 아는 것이 자연스럽고요. 만약 양방향 의존을 피하기 위해 검증의 신뢰도가 다소 떨어진다면, 주객전도라고 생각해요. 허브의 생각은 어떠신가요?

허브의 답변

이 부분에 대해서는 의존하지 않는 방향으로도 코드를 작성할 수 있을 것 같습니다.
하지만 현재 구조로는 많은 수정을 요구하는 것 같아요. -> Production 코드의 dto 반환 + 쿼리 전용 테스트 데이터를 넣어두는 것으로(하지만 복잡할 것 같네요)
그래서 검증의 신뢰성은 지키며, 최대한 의존하지 않는 방향으로 코드를 작성해가는 것으로 타협하는 것이 좋을 것 같아요.

예를들어 Member 테스트에 이벤트를 사용하며 필요없어진 PostRepository 등과 같은 부분은 제거했습니다.

[Combi153]

하지만 현재 구조로는 많은 수정을 요구하는 것 같아요. -> Production 코드의 dto 반환 + 쿼리 전용 테스트 데이터를 넣어두는 것으로(하지만 복잡할 것 같네요)

답변 감사해요. 그런 방법도 있겠네요. 그러면 검증의 신뢰성이 지켜질 것 같아요.

하지만 테스트의 신속성, 편의성 등이 떨어지겠네요. 허브 말씀대로 타협점을 찾으면서 해결합시다!

[greeng00se]

후추가 코멘트 남겨주신대로 현상황에서 기존의 방식대로 진행하는 것이 타협점이 될 것 같다는 생각이 드네요. 👍

[Jaeyoung22]

도메인 별로 패키지를 분리한 이상 철저하게 의존성도 분리되어야 한다고 생각합니다. 계층별 구조에서 슬라이스 테스트를 하듯이요. 다만 후추 말대로 검증의 신뢰성의 측면에서는 매번 mocking 하는 것이 이를 보장할 수 없을 것이라는 점에서도 동의합니다. 조금 더 논의해보죠.

[greeng00se]

status code에 대한 부분은 일관성을 위해 RestAssured에서 검증하도록 수정하는 것에 대한 허브의 답변

softly가 동작하기 이전에 실패하기 때문에 softly의 장점을 놓치는 건 아니라고 생각합니다!

후추가 말해준

단순히 상태코드만 반환하는 api 요청은 expect 절에서 상태코드를 검증하는 것이 적절하지만, 반환값이 있어 이를 확인해야 하는 api 요청에서는 then 절에서 상태코드를 검증하면 어떨까 합니다.

이 부분과 RestAssured에서 바로 검증하는 것 두 가지 중에 고민을 많이 했었고, 테스트의 검증부 가독성을 고려해서 statusCode를 RestAssured로 이동시켰습니다.

트레이드오프라고 생각하지만, 후추의 의견이 설득력이 있어서 검증은 then절에서 하도록 수정해보겠습니다!

[Combi153]

수정한 걸 또 수정하는게 여간 귀찮고, 어려운 일이 아닌데, 정말 감사합니다! 🚀