때로는 사내 다른 팀이 제공하는 컴포넌트를 사용한다. 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다.
Map 같은 경계 인터페이스를 이용할 때는 클래스나 클래스 계열 밖으로 노출하지 않도록 주의한다. 또한 map 인스턴스를 공개 api의 인수로 넘기거나 반환값으로 사용하지 말자. 그러면 map 인터페이스가 변하더라도 나머지 프로그램에는 영향을 미치지 않는다.
때로는 우리 버그인지 라이브러리 버그인지 찾아내느라 골치를 앓는다. ...곧바로 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익힌다면 외부 코드를 빨리 익힐 수 있다.이러한 과정을 학습 테스트라고 한다.
public class LogTest {
private Logger logger;
@Before
public void initialize() {
logger = Logger.getLogger("logger");
logger.removeAllAppenders();
Logger.getRootLogger().removeAllAppenders();
}
@Test
public void basicLogger() {
BasicConfigurator.configure();
logger.info("basicLogger");
}
@Test
public void addAppenderWithStream() {
logger.addAppender(new ConsoleAppender(
new PatternLayout("%p %t %m%n"),
ConsoleAppender.SYSTEM_OUT));
logger.info("addAppenderWithStream");
}
@Test
public void addAppenderWithoutStream() {
logger.addAppender(new ConsoleAppender(
new PatternLayout("%p %t %m%n")));
logger.info("addAppenderWithoutStream");
}
}
독자적인 로거 클래스로 캡슐화한 모습이다. 이를 이용하면 나머지 프로그램인 log4j 경계 인터페이스를 몰라도 된다.
학습 테스트는 투자하는 노력보다 얻는 성과가 더 크다. 학습 테스트는 패키지가 예상대로 도는지 검증한다. 이런 테스트가 없으면 패키지 새 버전이 나올때마다 새로운 위험이 생기고, 낡은 버전을 지나치게 오래 사용하고 싶은 유혹에 빠지기 쉽다.
아는 코드와 모르는 코드를 분리하자. 일단 아는 것부터 작업하다 보면, 점차 우리에게 필요한 경계 인터페이스가 무엇인지 깨달을 수 있다.
경계에 위치하는 코드는 깔끔히 분리하고, 관련 테스트 케이스를 이용해 관리하자. 이렇게 하면 향후 변경으로 인해 발생하는 비용을 줄일 수 있다.