[TDD Chapter8] 테스트 가능한 설계

🥨 테스트가 어려운 코드

개발을 진행하다보면, 테스트하기 어려운 코드들을 만나게 된다. 테스트하기 어려운 코드들은 다음과 같다.

1. 하드 코딩된 경로
2. 의존 객체를 직접 생성
3. 정적 메소드 사용
4. 실행 시점에 따라 달라지는 결과
5. 역할이 섞여 있는 코드
6. 그 외 테스트가 어려운 코드

🍗 하드 코딩된 경로

하드 코딩된 경로라함은 다음과 같이 코딩되어 있는 것을 뜻한다.

Path path = Paths.get("D:\\data\\pay\\cp0001.csv");

 

다음과 같이 되어 있는 코드를 테스트 하려면 해당 경로에 파일이 반드시 위치해 있어야 한다. 하지만, 윈도우에 다음과 같은 드라이브가 없거나 윈도우 전용 파일 경로이기 때문에 맥 OS, 리눅스에서는 파일을 열 수 없어 다른 OS를 갖고 있는 개발자 또한 테스트를 할 수 없다. 

 

하드 코딩된 경로 뿐만 아니라 하드 코딩 된 IP 주소, 포트 번호 또한 테스트를 어렵게 한다.

 

 

🍗 의존 객체를 직접 생성

또한 의존 대상을 직접 생성하는 것 또한 테스트를 하기 어려운 조건으로 만들고 있는 것이다. 

public class PaySync{

	// 의존 대상을 직접 생성
	private PayInfoDao payinfoDao = new PayInfoDao();
	
    public void sync() throws IOException{
    // 생략
    payInfos.forEach(pi -> payInfoDao.insert(pi));
    }
}

코드를 테스트하기 위해서는 저장된 데이터를 삭제해야 하는데 다음과 같이 코드를 작성하게 되면 데이터가 중복이 발생하여 테스트에 실패하게 된다. 다 같이 사용하지 않고, 한 번 생성하고 지워야 하는 객체들은 테스트 코드 아래에 작성하는 것이 좋다. 

 

🍗 정적 메소드 사용

정적 메소드를 사용하면 테스트를 하기 어려워진다.

boolean authorized = AuthUtil.authorize(authkey);


resp = AuthUtil.authenticate(id, pw);

 

위 코드는 AuthUtil 클래스의 정적 메소드를 사용하고 있다. AuthUtil 클래스가 인증 서버와 통신하는 경우 위 코드를 테스트 하려면 동작하고 있는 인증 서버가 필요하다. 따라서 클래스가 통신할 인증 서버 정보를 시스템 프로퍼티에서 가져온다면 시스템 프로퍼티도 테스트 환경에 맞게 설정해야하며, 인증 서버에 저장되어 있는 유요한 아이디와 암호를 사용해야 한다.

 

 

🍗 실행 시점에 따라 달라지는 코드

LocalDate now = LocalDate.now();

 

다음과 같은 코드가 있을 때, 테스트 코드를 작성하면 시간에 따라 테스트의 결과가 달라지므로 테스트를 믿을 수 없게 된다. 이와 같이 Random의 경우에도, 생성하는 결과 값이 랜덤으로 나오게 되므로 LocalDate와 같이 믿을 수 없는 상황이 발생할 수 있다. 

 

 

🍗 역할이 섞여 있는 코드

포인트 계산의 로직을 테스트하기 위한 코드에서는 로직만 가지고 테스트를 진행할 수 없다. 테스트를 진행하기 위해서는 DB에 접근하는 Dao에 대한 대역을 구성해야한다.

 

 

🍗  그 외 테스트가 어려운 코드

• 메서드 중간에 소켓 통신 코드가 포함
  • 소켓 통신이나 HTTP 통신은 실제 대체할 서버를 로컬에 띄워서 처리 가능, 서버 수준에서 대역을 사용한다고 생각
• 콘솔에 입력받거나 결과를 콘솔에 출력
• 테스트 대상이 사용하는 의존 대상 클래스나 메서드가 final -> 대역으로 대체가 어려울 수 있음
• 테스트 대상의 소스를 소유하고 있지 않아 수정이 어려움

728x90

🥨 테스트 가능한 설계

테스트가 어려운 주된 이유는 의존하는 코드를 교체할 수 있는 수단이 없기 때문이다. 따라서, 다음과 같이 코드를 교체하면서 테스트가 가능한 설게로 변경하는 것이 필요하다.

1. 하드 코딩된 상수를 생성자나 메서드 파라미터로 받기
2. 의존 대상을 주입 받기
3. 테스트하고 싶은 코드 분리하기
4. 시간이나 임의 값 생성 기능 분리하기 
5. 외부 라이브러리는 직접 사용하지 않고 감싸서 사용하기

 

🍗  하드 코딩된 상수를 생성자나 메서드 파라미터로 받기

하드 코딩된 경로가 테스트가 어려운 이유는 테스트 환경에 따라 경로를 다르게 줄 수 있는 수단이 없기 때문이다. 따라서, 상수를 쉽게 교체할 수 있는 기능을 추가하면 된다. 

public class PaySync{
	private String "D:\\data\\pay\\cp0001.csv"
    public void setFilePath(String filePath){
    	this.filePath = filePath;
	}
}

 

파일 경로를 변경하는 또 다른 방법은 메서드를 실행할 때 인자로 전달받는 것이다.

public class PaySync{
	private String "D:\\data\\pay\\cp0001.csv"
    
    public void sync(String filePath) throws IOException{
    	Path path = Paths.get(filePath);
	}
}

 

 

🍗  의존성 주입 받기

의존 대상은 주입받을 수 있는 생성자나 Setter 수단을 제공해서 교체할 수 있도록 한다. 이를 통해, 의존 대상을 교체할 수 있게 되면 실제 구현 대신에 대역을 사용할 수 있게 되어 테스트를 보다 원활하게 작성할 수 있게 된다. 

public class PaySync{
	// 생성자 추가 혹은
    public PaySync(PayInfoDao payInfoDao){
    	this.payInfoDao = payInfoDao;
	}
    
    // setter 추가
    public void setPayInfoDao(PayInfoDao payInfoDao){
    	this.payInfoDao = payInfoDao;
	}
}

 

🍗  테스트하고 싶은 코드 분리하기

코드 중에 기능 일부만 테스트를 하고 싶은 것이 있다면 그 코드를 별도 기능으로 분리하여 테스트를 진행할 수 있다.

 

 

🍗  시간이나 임의 값 생성 기능 분리하기

테스트 대상이 시간이나 임의의 값을 사용하면 테스트 시점에 따라 테스트 결과가 달라진다.  이 때, 테스트 대상이 사용하는 시간이나 임의의 제공하는 기능을 분리하여 테스트의 가능성을 높여야 한다. 

 

🍗  외부 라이브러리는 직접 사용하지 않고 감싸서 사용하기

테스트에서 사용하는 외부 라이브러리가 정적 메소드를 제공한다면 쉽게 대체할 수 없다. 

boolean authorized = AuthUtil.authorize(authkey);


resp = AuthUtil.authenticate(id, pw);

 

다음과 같은 코드는 정적 메소드이기 대문에 대역으로 대체하기 어렵다. 따라서, 외부 라이브러리를 직접 사용하지 않고, 외부 라이브러리와 연동하기 위한 타입을 새로 만든다. 그리고 테스트 대상은 분리한 타입을 사용하게 만든다. 

 

테스트 코드는 새로 분리한 타입을 생성함으로써 외부 연동이 필요한 기능을 쉽게 대역으로 교체할 수 있다. 

 

public class AuthService{
	private String = "somekey";
    
    public int authenticate(String id, String pw){
    	boolean authorized = AuthUtil.authorize(authKey);
        if(authorized){
        	return AuthUtil.authenticate(id, pw);
        }else {
        	return -1;
		}
	}
}