엘레강트 오브젝트 2장 - Education
2.7 문서를 작성하는 대신 테스트를 만드세요
Employee jeff = department.employee("jeff");
jeff.giveRaise(new Cash("$5.000"));
if (jeff.performance() < 3.5) {
jeff.fire();
}- 이상적인 코드는 스스로를 설명하기 때문에 어떤 추가 문서도 필요하지 않습니다.
- 문서화하는 대신 코드를 깔끔하게 만들기 바랍니다.
깔끔한 코드 - 단위 테스트도 함께 만든다.
- 깔끔하고 유지보수 가능한 단위 테스트를 추가하면, 클래스를 더 깔끔하게 만들 수 있고 유지 보수성을 향상 시킬 수 있다.
- 단위 테스트는 클래스의 일부이지 독립적인 개체가 아닙니다. => 개념적인 측면에서
느낀점
위의 예제 코드처럼 간단한 코드라면 저자가 말하는 이상적인 코드를 만드는데 힘을 많이 들이지 않아도 가능하겠지만, 보통 우리가 작성하는 코드는 저렇게 간단하지 않다고 생각한다. 테스트 코드를 잘 작성하면 문서화를 대신 하는 것 까지는 아니여도 코드를 이해하는데 훨씬 수월하다는 얘기는 많이 들었고 나도 동의한다. DisplayName이나 테스트 이름을 한글로 작성하면서 "어떤 상황에서 어떤 결과가 나와야한다." 라는 형식을 지키면서 해당 메서드가 어떤 역할을 하는지 알 수 있다고 생각한다.
2.8 모의 객체 대신 페이크 객체를 사용하세요.
class Cash {
private final Exchange exchange;
private final int cents;
public Cash(Exchange exchange, int cents) {
this.exchange = exchange;
this.cents = cents;
}
public Cash in(String currency) {
return new Cash(this.exchange,
this.cents * this.exchange.rate("USD", currency));
}
}- 테스트를 최적화하기 위한 장치라는 표현 방식은 모킹의 동작 방식을 잘 요약한 것이라고 생각합니다.
- 모킹은 나쁜 프랙티스이며, 최후의 수단으로만 사용해야 한다.
- 모킹 대신 페이크 객체를 사요할 것을 제안한다.
페이크 객체
public interface Exchange {
float rate(String source, String target);
final class Fake implements Exchange {
@Override
float rate(String origin, String target) {
return 1.2345;
}
}
}- 페이크 클래스는 인터페이스의 일부이며 인터페이스와 함께 제공됩니다.
- 페이크 클래스를 사용하면 테스트를 더 짧게 만들 수 있기 때문에 유지보수성이 눈에 띄게 향상됩니다.
- 모킹은 가정을 사실로 전환시키기 때문에 단위 테스트를 유지보수하기 어렵게 만든다.
모킹은 구현이 조금만 바껴도 다 깨지는 위험성을 지닌걸로 알고 있다. 모킹 테스트를 사용하는 것이 아닌 페이크 객체를 사용하면 구현이 바뀌어도 영향이 가는 위험성을 조금 줄일 수 있으니 좋은 것 같다. 활용을 하려면 더 공부를 해봐야 알 것 같다.
2.9 인터페이스를 짧게 유지하고 스마트를 사용하세요
인터페이스를 작게 만드는 것
- 클래스가 다수의 인터페이스를 구현하기 때문에 인터페이스를 작게 만들어야합니다.
- 인터페이스는 구현 클래스가 준수해야하는 계약입니다.
- 구현자에게 많은 것을 요구하면 단일 책임 원칙을 위반하는 클래스를 만들도록 부추깁니다.
=> 이는 응집도가 낮은 클래스를 만들게 합니다.데코레이터 패턴이 더 좋지 않을까?
