Java 코드베이스에서 나는 다음과 같은 패턴을 계속보고 있습니다.
/**
This is a stateless utility class
that groups useful foo-related operations, often with side effects.
*/
public class FooUtil {
public int foo(...) {...}
public void bar(...) {...}
}
/**
This class does applied foo-related things.
*/
class FooSomething {
int DoBusinessWithFoo(FooUtil fooUtil, ...) {
if (fooUtil.foo(...)) fooUtil.bar(...);
}
}
나를 귀찮게하는 FooUtil것은 테스트하기 때문에 모든 곳 의 인스턴스를 통과해야한다는 것 입니다.
FooUtil의 메소드를 정적으로 만들 수 없습니다 . 왜냐하면FooUtil클라이언트 클래스와 클라이언트 클래스 모두를 테스트하기 위해 모의 할 수 없기 때문 입니다.- 테스트를 위해 그것을 조롱 할 수 없기 때문에 다시
FooUtil소비 장소에서 인스턴스를 만들 수 없습니다new.
나는 내 최선의 방법은 주사를 사용하는 것이라고 가정하지만, 그것은 자신의 번거 로움을 추가합니다. 또한 여러 util 인스턴스를 전달하면 메서드 매개 변수 목록의 크기가 커집니다.
내가 보지 못하는 것을 더 잘 처리하는 방법이 있습니까?
업데이트 : 유틸리티 클래스는 상태가 없으므로 테스트를 위해 클래스의 기본 정적 필드를 업데이트하는 기능을 유지하면서 정적 싱글 톤 INSTANCE멤버 또는 정적 getInstance()메서드를 추가 할 수 있습니다 . 너무 깨끗해 보이지 않습니다.
4
그리고 단위 테스트를 효과적으로 수행하기 위해 모든 종속성을 조롱해야 한다는 가정 은 정확하지 않습니다 (나는 여전히 그 문제를 논의하는 질문을 찾고 있지만).
—
Telastyn
왜 이러한 메소드가 데이터를 조작하는 클래스의 멤버가 아닌가?
—
Jules
FooUtility 인 경우 정적 fns를 호출하는 별도의 Junit 세트를 보유하십시오. 그런 다음 조롱하지 않고 사용할 수 있습니다. 그것의 모의가 당신이 조롱해야한다고 생각한다면, 나는 단지 유틸리티가 아니라 IO 또는 비즈니스 로직을 수행한다고 생각하며 실제로 클래스 멤버 참조이어야하며 생성자, init 또는 setter 메소드를 통해 초기화되어야합니다.
—
tgkprog
Jules 댓글에 +1 유틸리티 클래스는 코드 냄새입니다. 시맨틱에 따라 더 나은 솔루션이 있어야합니다. 어쩌면
—
valenterry
FooUtil메소드를 넣을 FooSomething수도 있고, 더 이상 메소드가 필요하지 FooSomething않도록 속성을 변경 / 확장해야 할 수도 있습니다 FooUtil. FooSomething이 질문에 대한 올바른 답변을 제공하는 데 도움이 될만한 구체적인 예를 알려 주십시오.
@valenterry : util 클래스가 코드 냄새 인 유일한 이유는 Java가 독립형 함수를 갖는 좋은 방법을 제공하지 않기 때문입니다. 클래스에 특화되지 않은 함수를 갖는 데는 매우 좋은 이유가 있습니다.
—
Robert Harvey