title

JUnit 프레임워크에 준비되어 있는 @ArgumentProvider 구현체를 잘 사용하면 거의 모든 시나리오를 해결할 수 있다. 이 문서에서는 직접 사용한 케이스만 다룬다. 필요하다면 javadocs에 다른 참고 파일들도 직접 확인해보자.

1. @ValueSource: 가장 자주 사용한다. 테스트에 변인이 많으면 설명력이 떨어진다고 생각하기 때문에, 의도적으로 인자를 하나로 유지하는 편이다.
2. @NullAndEmptySource: 시작 케이스로 적합하다. 대체로 기본값과 대응되는 경우가 많다.
3. @MethodSource: 케이스를 직접 작성하기 어려운 경우에 적합하다. 케이스의 수가 많거나 복잡한 경우, 단순 나열에 비해 가독성이 높다.

[!example]

기본 구분자의 규칙에서 빈 배열을 반환하는 케이스는 null 또는 문자열이 isEmpty인 경우 뿐이다. 그러나 커스텀 구분자 규칙에서는 문자열 앞 부분에 규칙이 추가된다. 따라서, 규칙은 존재하지만, 이후 숫자가 비어있는 상태를 @ValueSource로 추가했다.

@ParameterizedTest
@NullAndEmptySource
@ValueSource(strings = {"//.\\n"})
void testParse_empty(String expression) {
    var actual = delimiter.parse(expression);
    assertThat(actual).isEmpty();
}

16진수 0xF는 4개의 비트(0b1111)로 표현된다. 따라서, char가 가질 수 있는 모든 범위를 탐색하기 위해서는 2 Byte로 표현할 수 있는, 0xFFFF까지의 문자를 확인하면 된다.¹

[!example]

다음 테스트는 basic latin 범위에 대해서는 @ParameterizedTest, 그리고 이후로는 일반 @Test를 활용하여 char 범위 전역에 대한 parse 메서드의 유효성을 판별하는 예제이다. ²

private static IntStream basicLatin() {
	return IntStream.rangeClosed(0x00, 0x7F) // [0, 127]
			.filter(value -> value != ',' && value != ':')
			.filter(value -> value < '0' || '9' < value);
}

@ParameterizedTest
@MethodSource(value = "basicLatin")
void testParse_function(int code) {
	var expression = String.format("//%c\\n1%c2%c3", code, code, code);
	var actual = delimiter.parse(expression);
	assertThat(actual).isEqualTo(List.of(1, 2, 3));
}

@Test
void testParse_BMPWithoutBasicLatin() {
	var codes = IntStream.rangeClosed(0x80, 0xFFFF);
	codes.forEach(this::testParse_function);
}

테스트 중 문제가 되는 문자의 유형을 크게 세 가지로 분류할 수 있었다.

1. 요구사항에서 명시한 예외 케이스: 기본 구분자는 커스텀 구분자가 될 수 없다는 도메인 규칙에 의한 예외이다.
2. 숫자 (0 ~ 9): 10진법을 활용한다면 대다수의 케이스에서 숫자 문자는 구분자로서의 역할을 제대로 수행할 수 없다. 따라서, 이러한 케이스는 자의적으로 배제하였다.

[!example]

다음 테스트는 숫자 또는 기본 구분자가 사용되면 예외가 발생한다는 사실을 표현한다.

private static IntStream charRangeNumbers() {
	return IntStream.rangeClosed('0', '9');
}

@ParameterizedTest
@MethodSource(value = "charRangeNumbers")
@ValueSource(ints = {',', ':'})
void testParse_invalidCustomDelimiterThrows(int code) {
	var expression = String.format("//%c\\n1%c2%c3", code, code, code);
	assertThrows(IllegalArgumentException.class, () -> delimiter.parse(expression));
}

3. 정규 표현식 문법
   • 표현식 문법에 사용되는 문자들을 비교식에 바로 삽입하면 문법적 오류가 발생할 수 있다. 따라서, Pattern.quote로 래핑할 필요가 있다.
   • 추가로 DOT을 활용하는 경우, 예외적으로 line terminator 문자들은 탐지 대상에서 제외한다. 이 부분은 DOTALL 플래그를 사용하면 동작을 변경할 수 있다. 자세한 내용은 Pattern 참고.

Info: surrogate pair

[!info] Java의 char는 UTF-16 기반의 2 Byte 자료형이다. 이 안에 세상 모든 문자를 담을 수 없음을 깨닫고, surrogate pair라는 개념을 활용해서 표현 범위를 확장했다. codePointAt은 UTF-16이 기본이지만, String의 생성자는 UTF-8이 기본이다. 인코딩 타입에 따른 활용 방식의 차이가 드러나도록 테스트를 작성해보았다.

private static IntStream emoji() {
	Supplier<Integer> utf8Code = () -> {
		byte[] utf8Bytes = new byte[]{(byte) 0xF0, (byte) 0x9F, (byte) 0xA4, (byte) 0x94};
		// String constructor use default charset UTF-8
		return new String(utf8Bytes).codePointAt(0);
	};

	return IntStream.of("🤔".codePointAt(0), // internally treated as UTF-16
			"\uD83E\uDD14".codePointAt(0), // UTF-16
			0x0001_F914, // UTF-32
			utf8Code.get() // UTF-8
	);
}

/**
 * BMP(Basic Multilingual Plane) 외부 문자의 surrogate pair 매칭 케이스
 */
@ParameterizedTest
@MethodSource("emoji")
void testParse_withSurrogatePair(int code) {
	var expression = String.format("//%c\\n1%c2%c3", code, code, code);
	assertEquals("//🤔\\n1🤔2🤔3", expression);
	var actual = delimiter.parse(expression);
	assertThat(actual).isEqualTo(List.of(1, 2, 3));
}

Footnotes

1. 물론 0xFFFF까지 확인하는 것도 하나의 문자에 대한 검증으로 완전하지는 않다. 문자들은 인코딩 방식에 따라 동일한 문자도 다른 바이트 코드로 입력될 수 있기 때문이다. link ↩

2. 일반 Test와 파라미터 테스트를 혼용한 것은 의도적이다. 이유는 테스트 결과를 확인하는 데 지나치게 시간이 많이 소요되기 때문. 현재 개발 환경에서 0xFFFF까지 약 6만 5천개의 테스트를 처리하는데 약 23초가 소요된다. 테스트 실행에 필요한 준비 작업들이 짧더라도, 테스트 개수가 이렇게 많으면 오래 걸릴 수 밖에 없다. 따라서, basic latin plane 이후로는 오버헤드가 생기지 않도록 반복문을 돌렸더니 600~800ms 정도 나온다. 못해도 30배 이상 차이나는 셈. ↩