Почему необязательное сообщение подтверждения в assertEquals переместилось на последнюю позицию в Junit 5? - PullRequest
0 голосов
/ 10 мая 2018

В JUnit 4 необязательное сообщение подтверждения было первым параметром в методе assertEquals. В JUnit 5 это последний.

Есть ли техническая причина, по которой он был перемещен в последнюю позицию? И если да, то какой?

Ответы [ 2 ]

0 голосов
/ 13 мая 2018

Я попытаюсь прояснить наш мыслительный процесс при разработке API JUnit 5 (который теперь проявляется в тестовом движке Jupiter) 3 года назад. Другие, которые присутствовали в то время (Марк Филипп, Сэм Браннен, Матиас Мердес и Стефан Бехтольд), могут вмешаться и исправить мои воспоминания ...

У нас было несколько основных ограничений:

  1. API JUnit 5 должен - с точки зрения компилятора - быть полностью отделенным от более старых версий, чтобы тесты из разных версий могли стоять рядом

  2. Тем не менее, API должен чувствовать себя знакомым, чтобы облегчить миграцию

  3. API должен включать в себя современное состояние и передовой опыт разработки Java API

Решение о том, что необязательный аргумент сообщения всех методов утверждения в org.junit.jupiter.api.Assertions всегда будет последним, было компромиссом между пунктами 2 и 3. Это имело еще больший смысл, поскольку мы допустили Supplier<String> messageSupplier аргументы. Использование лямбда-выражений в первой позиции оператора утверждения выглядело бы странно и отвлекало - так мы подумали.

Судя по ретроспективе, я бы, вероятно, выступил за более радикальное изменение API утверждений, чтобы избежать путаницы, затронутой в этом вопросе. Я даже настаивал на том, чтобы не использовать @Test в качестве основного маркера для методов тестирования, учитывая, как часто новички JUnit Jupiter импортируют старую аннотацию org.junit.Test и удивляются, почему система ведет себя странно.

0 голосов
/ 10 мая 2018

Об этом нужно будет спросить самих авторов, но в других библиотеках это общий шаблон.

Гуава Preconditions#checkNotNull например, или даже сам JDK в Objects#requireNoNull. В некотором смысле имеет смысл, чтобы этот необязательный параметр был «последним» ИМО (но это, конечно, на основе мнения).

...