인프런 커뮤니티 질문&답변
작성한 질문수
SystemUuidHolder를 테스트하는 경우
작성
·
441
답변 2
1
안녕하세요. 근래에 책을 집필할 기회가 생겨 그쪽에 힘을 실어주다 보니 다른 일에 신경 쓰지 못했습니다. 답변이 늦어 죄송합니다. 다만 해당 강의는 공식적으로 질의응답을 제공하지 않는 강의였다는 점을 이유로 늦어진 부분에 대해 양해 부탁드립니다.
질문이 2개인 것으로 이해했습니다.
하나는 SystemUuidHolder도 테스트해야 하는 것 아닌가?
또 다른 하나는 테스트는 FakeUuidHolder로 했더라도 결국 시스템이 실환경(Production)에 나가면 SystemUuidHolder가 사용될 테니 이에 대한 테스트는 다시 해야 하는 것 아닌가?
그래서 이를 바탕으로 각각에 대해 답변드립니다.
SystemUuidHolder도 테스트해야 하는 것 아닌가?
적어도 SystemUuidHolder의 동작 자체는 굳이 테스트하지 않아도 됩니다. 왜냐하면 UUID 클래스의 동작은 너무나 신뢰할 수 있기 때문입니다. 마찬가지로 Clock 클래스의 동작도 너무나 신뢰할 수 있기 때문에 SystemUuidHolder나 SystemClockHolder의 동작이 불완전할 가능성은 거의 0에 가깝습니다.
더불어 UUID나 Clock의 테스트는 UUID 클래스와 Clock 클래스를 만든 JDK 개발팀의 역할입니다. 그러니 UUID, Clock 메서드를 중개해 줄 뿐인 SystemUuidHolder, SystemClockHolder을 굳이 테스트할 필요는 없습니다. 따라서 실제 구현체를 테스트할지 말지 여부는 결국 ‘실제 구현체의 동작이 얼마나 신뢰할 수 있는가?’를 기준으로 판단해주면 됩니다.
테스트는 FakeUuidHolder로 했더라도 결국 시스템이 실환경(Production)에 나가면 SystemUuidHolder가 사용될 테니 이에 대한 테스트는 다시 해야 하는 것 아닌가?
이 내용은 강의 내에도 일부 포함된 것으로 아는데요. 1번 답변과 마찬가지로 SystemUuidHolder, SystemClockHolder의 동작은 확신할 수 있기 때문에 이 두 개는 test double이 사용된 테스트로도 충분하다 봅니다. 그런데 일부 라이브러리나 외부 시스템의 실 환경(Production)이나 준 실 환경(CBT)에서 다른 동작을 보일 수 있기 때문에 눈으로 보고 확인해야 하는 경우도 많습니다. 그런 경우에는 어쩔 수 없습니다. 수동 테스트나 대형 테스트를 만들어 테스트해야 합니다. (그런데 결국 이 주제는 mockist vs classicist입니다.)
답변이 도움 됐길 바랍니다. 감사합니다.
0
안녕하세요 노성규 님, 인프런 AI 인턴이에요.
프로젝트가 배포될 때 해당 클래스인 SystemUuidHolder를 사용하게 된다면, 해당 클래스에 대한 테스트를 진행하는 것이 좋습니다. 이는 코드의 안정성과 신뢰성을 확인하기 위함이며, 특히 UUID를 사용하는 상황에서는 final 메소드를 stub하는 것이 어렵기 때문에 해당 클래스에 대한 테스트가 더욱 중요해집니다.
마찬가지로, 완충재를 사용하여 테스트를 할 때에도 해당 클래스에 대한 테스트를 고려하는 것이 좋습니다. 테스트 시, 완충재를 사용하는 경우에도 원래의 구현체에 대한 테스트를 따로 작성함으로써 전체적인 코드의 품질을 유지할 수 있습니다.
즉, SystemUuidHolder와 같은 구현체에 대한 테스트는 코드의 안정성과 기능을 검증하는 데 중요한 역할을 하므로, 해당 클래스에 대한 테스트를 진행하는 것을 권장합니다. 감사합니다!
답변 감사합니다!
해당 강의를 듣고 테스트에 대해 더 궁금해져서 관련 책을 읽으면서 비슷한 생각을 하고 있었는데 답변으로 조금 더 확신을 얻게 된 것 같습니다!!