Зачем ?
Нууу, мне кажется, что такая абстрактная ошибка List size mismatch: expected: > 16 не говорит о сути проблемы, в отличие от ошибки типа ‘Amount of rows in table A should be >= 8’
Ну то есть конкретики же больше можно засунуть в свою ошибку, или, наоборот, меньше(там где это действительно нужно), что в будущем улучшит дебаг тестов. Разве нет ?
Что по факту изменится?
Тому, кто получит отчёт об упавшем тесте, по-любому придётся открыть стактрейс, открыть нужную строчку в коде и смотреть, что там нужно исправить. В этом смысле сообщение “Amount of rows in table A should be >= 8” ничего не упростит.
Сейчас есть метод because, он примерно из той же области, но есть разница. Он нужен не для того, чтобы поменять сообщение об ошибке, а для того, чтобы объяснить, почему именно такой condition ожидается. Примерно так:
$(".error").shouldBe(visible.because("After 3 unsuccessful login attempts, user should see an error message"));
P.S. Вижу, что в AssertJ есть метод “as”, и по-моему, он по сути такой же, как селенидовский “because”: assertThat(myTest).as("The test microservice is not active").isEqualTo("active");
P.S. В целом можно подумать и над тем, чтобы кастомизировать сообщение об ошибке. Я посмотрел, что в AssertJ есть методы withFailMessage и overridingErrorMessage, но пока мне не очень понятно, в какой ситуации они могут быть полезны. Они перетирают дефалтовое сообщение, но в нём же масса полезной информации…