testomat.io управление авто тестамитоже что и Assert просто вначале указывается имя действия проверки
вроде
new Check(“Search Results”).areEquals(tableResults, expected);
выведет в лог
'>> Check Search Results equals to < expected> - до выполнения ассерта
и если в ассерте упадет ошибка, то перед ним будет мнемоническое название того, что проверялось
Извините, но чем плохи дефолтные JUnit, Testng, Hamcrest ассерты? Там есть 3е поле - description. Не говоря уже о Selenide (с его .because в кондишенах).
Зачем городить new …
Вы забыли еще Яндексовские матчеры 
Тот же вопрос можно адресовать Selenid-у или hamcrest-у У каждого что-то свое, почитайте, попробуйте изучите, если интересно. Если был бы один идеальный асерт класс, их бы не было так много )
Но объясните ощутимый профит пожалуйста. Может ваша реализация окажется лучше чем иные (для кого-нибудь из сообщества).
Это будет офтопик. Наши матчеры мы будем презентовать позднее и это не сильно относится к фреймворку.
Но из интересных, на мой взгляд, моментов.
- Настройка возможности бросать различные виды эксепшенов (допустим TestNG, или Junit или просто Exception или не бросать, а просто писать в лог). В идеале планируется подход вроде Log4J с выбором “каналов”(способов) бросания эксепшенов
- Все проверки можно делать как с уже посчитанными данными, так и с функциями (пример: “пока текст элемента не станет равен ожидаемому в течении таймаута”)
Assert.areEquals(() -> $(…).getText(), “Expected text”) - Сложные ассертоы, списки, массивы, (contains, match), XML, файлы, картинки
- Режим Verify собирающий ошибки по всему тесту и бросающий список всех ошибок в конце теста
Но не думаю, что готов сейчас это обсуждать
Считайте это Тизером ))
Роман, такой вопрос - как подружить JDI c JUnit?
Просто по умолчанию он работает с TestNG.
Или ткните меня в документацию, где это написано. Я не нашел, к сожалению.