명명 패턴의 문제점
junit을 이용해 테스트 코드를 작성할 때 @Test 어노테이션이 익숙하다. 하지만 junit 3 이하 버전에서는 명명 패턴을 활용해 테스트 코드를 인식했다. test라는 글자가 메서드에 붙어야 하는데 잘못된 형식으로 작성하거나 tset과 같이 오타의 경우 테스트 코드를 찾지 못한다. 심지어 예외를 발생하지도 않는다. 그러나 테스트의 실패가 없으니 사용자는 테스트를 통과했다고 착각할 수도 있다.
어노테이션을 이용해 명명패턴 문제점 해결
어노테이션은 코드를 정의하고 IDE의 정적 분석을 활용해 오타를 잡아낼 수 있다.
@Target({ElementType.ANNOTATION_TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@API(
status = Status.STABLE,
since = "5.0"
)
@Testable
public @interface Test {
}위의 코드는 junit4부터 도입된 @Test 어노테이션이다. 이는 매개 변수없이 특정한 메서드를 마킹하기 때문에 마커 어노테이션으로도 불린다.
해당 어노테이션의 장점은 어노테이션 타입과 메소드 타입에 강제되며, RUNTIME 동안 적용된다. 이러한 특징이 지니는 장점은 @Test 어노테이션이 붙은 타입은 메서드나 어노테이션만 가능하며 메서드가 아닌 곳에 테스트를 정의하면 컴파일러가 이를 잡아낼 수 있다. 이는 명명 패턴과 달리 실수할 여지를 줄일 수 있다.
어노테이션은 명명패턴이 할 수 없는 일도 가능하다
Runtime동안 마킹되는 특성 때문에 리플렉션을 활용해 해당 클래스나, 메서드, 프로퍼티 등이 어노테이션을 가지고 있는지 확인할 수 있고 이를 처리하는 프로그램을 만들 수 있다. 경우에 따라 매개 변수를 전달 할 수 있다. 이것만으로도 굉장히 파워풀하지만 재사용성도 탁월한 장점이 있다.
예를 들어 AOP를 활용한다고 가정하자. spring aop의 경우 패키지 경로와 메서드 네이밍의 규칙을 활용해 aop를 적용할 수 있다. 이것의 단점은 네이밍에 의존하기 때문에 네이밍이 바뀌면 더이상 aop를 적용할 수 없다는 점과 추가 메서드가 구현되면 매번 aop pointcut을 작성해야 할 수도 있다.
그러나, 어노테이션을 활용해서 aop를 설계하면 내가 필요한 부분에 어노테이션만 붙이면 그 코드는 aop가 적용된다. 따로 코드를 작성할 필요 없이 어노테이션만 추가하면 적용되기 때문에 확장성과 재활용성 또한 뛰어나다고 할 수 있다.
결론
명명패턴을 사용해야 하는 경우가 생긴다면 명명패턴보다 어노테이션을 활용하자
