JUnit использует этот синтаксис, чтобы показать, почему тест не прошел, а именно, когда ожидаемая строка не соответствует фактическому значению:
String expected = "[1, 2, 3, 4, 5, 6, 7, 8, 9, 89]";
List<Long> actualLongs = Arrays.asList(
1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L,
1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 89L);
String actualString = actualLongs.toString();
assertEquals(expected, actualString);
JUnit выясняет, что сходно и чем отличается между ожидаемым и фактическим, и использует квадратные скобки, чтобы выделить это. Если вы выровняете биты «ожидаемый» и «но был», вы получите:
expected:<..., 4, 5, 6, 7, 8, 9, []89]>
but was:<..., 4, 5, 6, 7, 8, 9, [1, 2, 3, 4, 5, 6, 7, 8, 9, ]89]>
... так что это говорит о том, что в этом []
пробеле он не ожидал ничего лишнего, но нашел символы 1, 2, 3, 4, 5, 6, 7, 8, 9,
.
Разница становится немного более очевидной, если это не просто дополнительные символы. Например, предположим, что у вас не было дополнительных значений, но последние 89 были вместо 66. Тогда это будет выглядеть так:
expected:<..., 4, 5, 6, 7, 8, 9, [89]]>
but was:<..., 4, 5, 6, 7, 8, 9, [66]]>
«Там, где я ожидал 89, я нашел 66».
Я не так хорошо знаком с TestNG, но меня не удивит, если он сделает подобное.
Если вы запустите тест в IDEA IntelliJ, он даже уловит этот синтаксис и покажет вам отличное представление ожидаемого, но ожидаемого. Опять же, я не знаком с другими IDE (например, Eclipse), но меня это не удивит, если они тоже так сделают.