2020.04.16-개발일지

클린 코드를 다시 읽던 중, 8장 ‘경계’ 에서 ‘학습 테스트는 공짜 이상이다 라는 주제가 많은 공감이 되었습니다.

···

학습 테스트는공짜 이상이다. 투자하는 노력보다 성과가 크다. 패키지 새 버전이 나온다면 학습 테스트를 돌려 차이가 있는지 확인한다.

···

일단 통합한 이후라고 하더라도 패키지가 우리 코드와 호환되라라는 보장은 없다. 패키지 작성자에게 코드를 변경할 필요가 생길지도 모른다.

···

이런 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다. 그렇지 않다면 낡은 버전을 필요 이상으로 오랫동안 사용하려는 유혹에 빠지기 쉽다.

책에서는 이와 같은 내용으로 설명하면서, 인터페이스를 예시로 들었습니다.

변경은 생각보다 무서운 일

언젠가 회사에서 라이브러리 버전업 업무가 생겼습니다. 처음에는 단순히 숫자만 변경하면 해결되지 싶었습니다. 그러나 패키지 명 등의 변경이 있는 Major 업그레이드였고 책에 나오는 내용처럼 낡은 버전을 사용하고 싶은 욕구가 생겼습니다. 버전업을 주저하게 하는 가장 큰 이유는 해당 기능에 대한 이해도가 없었기 떄문입니다. 어떤 함수를 호출하는지, 어떤 기능을 하는지 …. 적어도 이 애플리케이션에서 사용하는 만큼만이라도 기록해두었더라면 손쉽게 변경할 수 있었을 것입니다. 결국 오랜 시간을 투자하여 수많은 테스트 코드를 실행하고 구글링 하였습니다. 이 후 버전업해도 좋겠다는 결론이 내려졌고, 현재까지 별문제 없이 운영 중에 있습니다.

알게된 점

Learning Test 란 말을 잘못 이해했는지도 모르겠습니다. 구글링하면 문자 그대로 학습 으로 검색됩니다. 오히려 한글로 학습테스트 또는 clean code learning test 라고 검색하면 일부 자료가 나오긴 합니다. 해당 내용을 바탕으로, 정답이 아닐수도 있지만,학습테스트란 이름의 패키지를 생성하고 사용했던 라이브러리들 중 특이한 것에 대해 상세하게 작성하면 어떨까 싶었습니다.

테스트를 분리하자

리팩토링을 하면서 reflection 라이브러리를 사용하였습니다. 일반적으로 얼마나 많이 사용되는지는 모르겠지만, 혹시 모를 다른 사람이 본다면 또는 내가 이후에 본다면 하는 생각으로 일종의 저만의 학습테스트를 작성했습니다.

package learningtest;

import menu.MenuMapper;
import org.junit.Test;
import org.reflections.Reflections;

import java.util.Set;

/**
 *
 * 	<h1>org.reflection 패키지의 사용용도와 방법을 위한 테스트 클래스</h1>
 *
 *	<p>
 *		애플리케이션 실행 시, Annotation 이 선언된 클래스의 정보를 가져오기 위해 사용했습니다.
 *		Class 객체를 이용시 현재 실행하고 있는 객체의 정보만을 가져오지만, 본 라이브러리를 이용시
 *		동적으로 클래스 정보를 가져 올 수 있습니다.
 *  </p>
 *
 *  <b>
 *      주의 : 하기 테스트 이외에 메서드를 사용하지 않았습니다.
 *  </b>
 *
 * @see org.reflections
 * @see menu.MenuSelector
 * @see menu.MenuMapper
 */
public class ReflectionTest {

	/**
	 * 탐색을 원하는 Annotation 타입을 given에 설정합니다.
	 * 이후 클래스 정보를 출력할 때, 매칭 되는 결과 값을 확인합니다.
	 */
	@Test
	public void getAnnotatedClasses() {

		//given
		Class annotation = MenuMapper.class;

		//when
		Reflections reflections = new Reflections();
		Set<Class<?>> cls = reflections.getTypesAnnotatedWith(annotation);

		//then
		cls.stream().forEach(clz -> System.out.println(clz.getName()));
	}

}