인프런 커뮤니티 질문&답변
작성한 질문수
'코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다
해결된 질문
작성
·
68
·
수정됨
1
우빈님 안녕하세요!
'코틀린'에서는 빌더를 따로 쓰지 않는데, 이 때는 어떻게 test fixture를 만드시는지 궁금합니다 ㅎㅎ
저도 그동안 실무에서 자바를 쓰면서 테스트에서 given 절의 test fixture는 빌더로 만들어서 사용하고, 프로덕션에서는 팩토리 메서드로 객체를 생성해왔습니다. (물론 이 강의를 보고나서부터입니다 ㅎㅎ)
그런데 코틀린을 쓰다보니까 롬복을 거의 쓸 일이 없는 것 같더라고요.
private constructor & 팩토리 메서드를 코틀린에서 쓰다 보니까 팩토리 메서드로만 객체를 생성해야해서 테스트에서 '맥락을 이해하는데 허들이 하나 더' 생기는 꼴이 되고 있어 조금 고민입니다..
그렇다고 테스트 전용 팩토리 메서드 같은 것을 만들자니 프로덕션에 테스트 관련된 소스가 바로 생기는 것은 영 석연치 않더라고요.
그래서 지금은 일단 생성자를 public으로 열어두고, 팩토리 메서드가 있는 도메인 객체를 만들 때는 무조건 팩토리 메서드만 쓴다. 그리고 테스트에서는 테스트 용이성을 위해 생성자로 객체를 생성하는 것을 허용하는 것으로 해보려고 합니다.
혹시 위 같은 상황에서 우빈님은 어떤 기준으로 쓰고 계신지 궁금합니다..!
바쁘실텐데도 시간 내어 확인해주셔서 감사합니다 :)
답변 2
1
안녕하세요, eomuksoyummy 님!
저도 말씀하신 방법처럼 하고 있어요.
자바에서 Builder를 사용하는 이유 중 하나는 파라미터를 단순 순서가 아닌 이름 기반으로 매칭하여 가독성을 높이고 실수를 줄일 수 있다는 것인데요.
코틀린에서는 생성자 단에서 이름 기반 매칭을 지원하기 때문에, 생성자를 활용하면 충분히 같은 효과를 가질 수 있습니다.
추가로 코틀린에서의 Fixture 정의가 필요한 경우도 생각해볼 수 있는데요. 만약 실제 프로덕션 생성자에서는 A라는 파라미터가 필수값일 수 있는데, 테스트코드에서는 A라는 파라미터가 주어지지 않으면 특정 값이 기본 값으로 설정되도록 미리 정의해둘 수도 있습니다.
팩토리 메서드를 정의했다고 해서 반드시 생성자를 private으로 둘 필요는 없으니, 언어의 특성에 맞게 (명확한 이유가 있는) 컨벤션을 정하고 적용해보면 좋을 것 같네요.
도움이 되셨기를 바랍니다.
감사합니다. 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
eomuksoyummy님께서 말씀하신 것처럼 코틀린에서는 롬복이나 빌더 패턴을 자주 사용하지 않습니다. 대신 코틀린의 특징들을 활용하여 테스트 핑하기 적합한 방법들을 제공합니다.
코틀린에서는 데이터 클래스를 이용하여 객체를 간단하게 생성할 수 있으며, 이로 인해 테스트 시에 필요한 객체를 쉽게 생성할 수 있습니다. 데이터 클래스는 copy 메서드를 자동 생성하여, 객체의 특정 속성만을 변경한 새로운 인스턴스를 쉽게 만들 수 있도록 해줍니다. 아래는 간단한 예시입니다:
data class User(val id: Int, val name: String)
// Test fixture 생성
val userFixture = User(1, "Alice")
val updatedUserFixture = userFixture.copy(name = "Bob")
물론 이 방법 외에도, 팩토리 메서드를 이용하고, 테스트에서 생성자를 직접 사용하는 것도 좋은 방법입니다. 이것은 프로덕션 코드와 테스트 코드 간의 분리라는 관점에서 이해할 수 있습니다.
팩토리 메서드는 객체 생성 로직을 캡슐화하여 사용의 일관성을 제공합니다. 테스트에서는 이러한 일관성을 유지하면서도 유연성을 보장하기 위해 가능하면 데이터 클래스를 사용하거나 테스트용 생성자를 사용하여 객체를 생성하는 것을 고려할 수 있습니다.
이 외에도, 모킹 라이브러리나 테스트 도우미 유틸을 사용하여 테스트 환경을 구축하면 더욱 효과적으로 테스트를 수행할 수 있습니다.
코틀린에서는 MockK와 같은 라이브러리가 널리 사용되며, 경우에 따라 @MockkBean 및 @SpykBean을 참고하여 필요한 상황에 맞게 환경을 설정할 수 있습니다. 추가적으로, 스프링의 SpringMockK도 활용 가능합니다.
테스트의 목적에 충실하면서도 코드의 유지 보수성을 고려한 방법을 선택하는 것이 중요합니다. 더 궁금한 사항이 있으시면 언제든지 질문 해주세요!
감사합니다.