Действительно, под капотом в итоге и у нас простые методы в духе assertEquals, isNull, NotNull и т.п. - это, как говорится, база. Но в том то и дело, что это самые простые базовые проверки.
Возможно, для юнит-тестов подойдет и вариант с простыми проверками типа assertEquals. Если предположить, что эта обертка будет использоваться не более чем пару раз, то да, написание таких методов - это излишне.
Однако, у нас в проекте идет компонентное тестирование, чуть посложнее дела обстоят. Написание этой самой "обертки" наоборот нам упрощает жизнь, ведь этот метод проверки будет использоваться в большом количестве тестов, думаю в десятках, сотнях, а в перспективе и до тысяч раз. Лучше один из наших разработчиков напишет метод, проверит его корректность, а остальные уже будут этот метод использовать в своих тестах. За счет этого впоследствии ускоряется время разработки тестов.
Также, в нашем проекте делается упор на описание шагов теста через Allure. Соответственно, нам так гораздо проще поддерживать единый стиль этих самых "шагов" - ведь все под рукой в пределах класса, а не разбросано по сотням тестов, где каждый пишет как хочет.
Помимо этого, многие данные для проверки бывает не так-то и просто получить из проверяемого нами ПО. Условно, для получения некоторых данных нужно сделать "два притопа, три прихлопа". Например, у документов есть "статус", и зачастую по ходу теста нам приходится ждать по таймеру изменение этого статуса пока тестируемое ПО обработает этот документ.
Почти всегда в рамках одного теста нам нужно проверять множество атрибутов объекта. Если это делать без оберток, прописывая все шаги Allure, всю сложную логику проверок полей(если она есть), то тело теста, на мой взгляд, будет трудночитаемым.
Такие вот дела. Надеюсь, что смог немного прояснить свое видение плюсов данного подхода.
Добрый день. Спасибо за вопрос!
Действительно, под капотом в итоге и у нас простые методы в духе assertEquals, isNull, NotNull и т.п. - это, как говорится, база. Но в том то и дело, что это самые простые базовые проверки.
Возможно, для юнит-тестов подойдет и вариант с простыми проверками типа assertEquals. Если предположить, что эта обертка будет использоваться не более чем пару раз, то да, написание таких методов - это излишне.
Однако, у нас в проекте идет компонентное тестирование, чуть посложнее дела обстоят. Написание этой самой "обертки" наоборот нам упрощает жизнь, ведь этот метод проверки будет использоваться в большом количестве тестов, думаю в десятках, сотнях, а в перспективе и до тысяч раз. Лучше один из наших разработчиков напишет метод, проверит его корректность, а остальные уже будут этот метод использовать в своих тестах. За счет этого впоследствии ускоряется время разработки тестов.
Также, в нашем проекте делается упор на описание шагов теста через Allure. Соответственно, нам так гораздо проще поддерживать единый стиль этих самых "шагов" - ведь все под рукой в пределах класса, а не разбросано по сотням тестов, где каждый пишет как хочет.
Помимо этого, многие данные для проверки бывает не так-то и просто получить из проверяемого нами ПО. Условно, для получения некоторых данных нужно сделать "два притопа, три прихлопа". Например, у документов есть "статус", и зачастую по ходу теста нам приходится ждать по таймеру изменение этого статуса пока тестируемое ПО обработает этот документ.
Почти всегда в рамках одного теста нам нужно проверять множество атрибутов объекта. Если это делать без оберток, прописывая все шаги Allure, всю сложную логику проверок полей(если она есть), то тело теста, на мой взгляд, будет трудночитаемым.
Такие вот дела. Надеюсь, что смог немного прояснить свое видение плюсов данного подхода.