•
테스트 대상 클래스를 테스트 하네스에서 생성할 수 있게 되었다면 다음은 메소드를 실행해야 한다.
•
대체로 메소드에 대한 테스트 루틴을 작성하기 위해 필요한 작업량은 그렇게 많지 않으며 이 과정에서 부딪칠 수 있는 문제는 다음과 같다.
◦
메소드를 테스트 루틴에서 접근할 수 없는 경우, private나 그 밖의 가시성 문제
◦
메소드 호출에 필요한 매개변수를 생성하기 어려운 경우
◦
메소드에 부정적인 부작용 때문에 실행이 불가능한 경우
◦
메소드가 사용하는 객체들을 사전에 감지해야 하는 경우
숨어있는 메소드
•
레거시 클래스 내의 메소드를 변경해야 하는데, 그 메소드가 private 메소드일 경우 어떻게 해야할까?
◦
public 메소드를 통해 테스트 가능할지 검토해봐야 한다. 가능하다면 시도해볼 가치가 있다.
•
그렇지 않은 경우, 테스트하려면 그 메소드를 public으로 만들어야 한다.
◦
public으로 만드는 것이 꺼려진다면 이는 곧 클래스가 너무 많은 책임을 가지고 있음을 의미하며 수정이 필요함을 뜻한다.
•
private 메소드를 public으로 만드는 것이 왜 우리를 고민하게 만들까? 다음과 같은 이유들이 있다.
◦
이 메소드는 단지 유틸리티다. 즉 호출 코드는 이 메소드를 신경 쓰지 않는다.
◦
호출 코드에서 이 메소드를 직접 사용하는 경우, 클래스의 다른 메소드의 결과에 영향을 미칠 수 있다.
▪
이 경우, private 메소드를 신규 클래스로 옮긴 후, 이 메소드를 public으로 선언함으로써 기존 신규 클래스에서 인스턴스를 생성할 수 있다.
언어의 편리한 기능
•
이 경우는 보통 final, sealed와 같은 키워드가 붙어 보안의 이유로 해당 클래스를 직접 생성하지 못하게 만드는 경우 해당한다.
•
메소드 호출에 필요한 매개변수를 생성하기 위해 메소드 매개변수를 해당 클래스의 상위 클래스로의 타입 변경해볼 수 있다.
◦
해당 경우, 테스트 대역 클래스를 만들어 메소드 호출에 적절한 객체를 제공해줄 수 있다.
탐지 불가능한 부작용
•
GUI에 뭔가를 표시한다거나 데이터베이스 조작이 발생하는 경우가 해당한다.
•
테스트를 위해서 해당 부작용에 의존적인 부분과 그렇지 않은 부분을 분리해야 한다.
•
즉, 메소드 추출 기법을 사용해 리팩토링을 적극 수행하여 테스트 가능하게 범위를 제한하는 것이 필요하다.
