Я попытаюсь прояснить наш мыслительный процесс при разработке API JUnit 5 (который теперь проявляется в тестовом движке Jupiter) 3 года назад. Другие, которые присутствовали в то время (Марк Филипп, Сэм Браннен, Матиас Мердес и Стефан Бехтольд), могут вмешаться и исправить мои воспоминания ...
У нас было несколько основных ограничений:
API JUnit 5 должен - с точки зрения компилятора - быть полностью отделенным от более старых версий, чтобы тесты из разных версий могли стоять рядом
Тем не менее, API должен чувствовать себя знакомым, чтобы облегчить миграцию
API должен включать в себя современное состояние и передовой опыт разработки Java API
Решение о том, что необязательный аргумент сообщения всех методов утверждения в org.junit.jupiter.api.Assertions
всегда будет последним, было компромиссом между пунктами 2 и 3. Это имело еще больший смысл, поскольку мы допустили Supplier<String> messageSupplier
аргументы. Использование лямбда-выражений в первой позиции оператора утверждения выглядело бы странно и отвлекало - так мы подумали.
Судя по ретроспективе, я бы, вероятно, выступил за более радикальное изменение API утверждений, чтобы избежать путаницы, затронутой в этом вопросе. Я даже настаивал на том, чтобы не использовать @Test
в качестве основного маркера для методов тестирования, учитывая, как часто новички JUnit Jupiter импортируют старую аннотацию org.junit.Test
и удивляются, почему система ведет себя странно.