[java] 추상 클래스를 단위 테스트하는 방법 : 스텁으로 확장?

추상 기본 클래스가 사용되는 두 가지 방법이 있습니다.

1. 추상 객체를 전문화하고 있지만 모든 클라이언트는 기본 인터페이스를 통해 파생 클래스를 사용합니다.

2. 디자인의 객체 내에서 중복을 제거하기 위해 추상 기본 클래스를 사용하고 있으며 클라이언트는 자체 인터페이스를 통해 구체적인 구현을 사용합니다.!

---

1 전략 패턴에 대한 솔루션

첫 번째 상황 인 경우 실제로 파생 클래스가 구현하는 추상 클래스의 가상 메소드로 정의 된 인터페이스가 있습니다.

이것을 실제 인터페이스로 만들고 추상 클래스를 구체적으로 변경하고 생성자에서이 인터페이스의 인스턴스를 가져와야합니다. 파생 클래스는이 새로운 인터페이스의 구현이됩니다.

즉, 이제 새로운 인터페이스의 모의 인스턴스를 사용하여 이전 추상 클래스를 테스트 할 수 있으며 이제는 공용 인터페이스를 통해 각각의 새로운 구현을 테스트 할 수 있습니다. 모든 것이 간단하고 테스트 가능합니다.

---

2를위한 해결책

두 번째 상황이있는 경우 추상 클래스는 도우미 클래스로 작동합니다.

포함 된 기능을 살펴보십시오. 이 복제를 최소화하기 위해 조작중인 물체에 밀어 넣을 수 있는지 확인하십시오. 여전히 남아있는 것이 있다면 구체적인 구현이 생성자를 가져와 기본 클래스를 제거하는 도우미 클래스로 만드는 것을보십시오.

이것은 간단하고 쉽게 테스트 할 수있는 구체적인 수업으로 이어집니다.

---

원칙적으로

복잡한 복잡한 네트워크를 통해 단순한 단순한 네트워크를 선호합니다.

확장 가능한 테스트 가능 코드의 핵심은 작은 빌딩 블록과 독립적 인 배선입니다.

---

업데이트 : 두 가지 혼합물을 처리하는 방법?

이 두 역할을 모두 수행하는 기본 클래스를 가질 수 있습니다. 즉, 공용 인터페이스가 있으며 도우미 메소드를 보호합니다. 이 경우 도우미 메소드를 하나의 클래스 (시나리오 2)로 인수 화하고 상속 트리를 전략 패턴으로 변환 할 수 있습니다.

기본 클래스가 직접 구현하고 다른 메소드가 가상 인 일부 메소드가있는 경우에도 상속 트리를 전략 패턴으로 변환 할 수 있지만 책임이 올바르게 정렬되지 않았 음을 나타내는 좋은 지표로 사용할 수도 있습니다. 리팩토링이 필요합니다.

---

업데이트 2 : 디딤돌로서의 추상 클래스 (2014/06/12)

요 전에는 초록을 사용한 상황이 있었으므로 그 이유를 살펴보고 싶습니다.

구성 파일에 대한 표준 형식이 있습니다. 이 특정 도구에는 해당 형식으로 된 3 개의 구성 파일이 있습니다. 종속성 설정을 통해 클래스가 관심있는 설정을 요청할 수 있도록 각 설정 파일에 대해 강력한 유형의 클래스를 원했습니다.

설정 파일 형식을 구문 분석하는 방법을 알고있는 추상 기본 클래스와 동일한 방법을 노출하지만 설정 파일의 위치를 ​​캡슐화 한 파생 클래스를 사용하여이를 구현했습니다.

3 개의 클래스가 래핑 된 “SettingsFileParser”를 작성한 다음 기본 클래스에 위임하여 데이터 액세스 방법을 노출 할 수있었습니다. 나는 다른 어떤 것보다 더 많은 위임 코드를 가진 3 개의 파생 클래스로 이어질 수 있기 때문에 아직 이 작업을 수행하지 않기로 선택했습니다 .

그러나 …이 코드가 발전하고 이러한 각 설정 클래스의 소비자가 더 명확 해집니다. 각 설정 사용자는 몇 가지 설정을 요구하고 어떤 방식 으로든 설정을 변경합니다 (설정은 텍스트이므로 설정을 숫자 등으로 변환하는 개체로 래핑 할 수 있습니다). 이런 일이 발생하면이 논리를 데이터 조작 방법으로 추출하고 강력한 형식의 설정 클래스로 다시 밀어 넣습니다. 이는 각 설정 세트에 대해 더 높은 수준의 인터페이스로 연결되어 결국 ‘설정’을 다루는 것을 더 이상 인식하지 못합니다.

이 시점에서 강력한 형식의 설정 클래스는 더 이상 기본 ‘설정’구현을 노출하는 “게터”메소드가 필요하지 않습니다.

그 시점에서 나는 더 이상 공개 인터페이스에 설정 접근 자 메소드를 포함시키지 않기를 원합니다. 따라서이 클래스를 변경하여 설정 파서 클래스를 캡슐화하지 않고 변경합니다.

따라서 Abstract 클래스는 현재 위임 코드를 피할 수있는 방법이며 코드의 마커는 나중에 디자인을 변경하도록 상기시킵니다. 나는 그것을 얻지 못할 수도 있으므로 좋은 시간 동안 살 수 있습니다 … 코드 만 말할 수 있습니다.

“정적 메소드 없음”또는 “비공개 메소드 없음”과 같은 규칙에서이 사실을 발견했습니다. 그들은 코드에서 냄새를 나타냅니다 … 그리고 좋습니다. 그것은 당신이 놓친 추상화를 계속 찾고 … 그 동안 고객에게 가치를 계속 제공합니다.

계곡에 유지 가능한 코드가있는 풍경을 정의하는 것과 같은 규칙을 상상합니다. 새로운 행동을 추가하면 코드에 비가 오는 것과 같습니다. 처음에는 착륙 할 때마다 그것을 배치합니다. 그런 다음 리팩터링하여 좋은 디자인의 힘이 모든 동작이 계곡에서 끝날 때까지 행동을 옮길 수 있도록합니다.

---

답변