Если нельзя, но очень хочется - то можно.
Решил написать про отложенные ассерты.
Эта техника появилась у нас более года назад.
Аналогичная техника есть в TestNG - там она называется SoftAssert.
Прочитать про нее можно вот тут и тут.
От TestNG мы отказались и их SoftAssert-ами никогда не пользовались, а вот техника прижилась.
Мне очень не нравится слово SoftAssert - ассерт не может быть мягким.
Мы называем это Delayed Assert - ассерт все равно случится и если условие не выполнено тест упадет, но сделает это позже, пройдя через еще пару точек проверки (может быть :)).
Чтобы это сделать нужно написать полноценный end-to-end тест, который пройдет через всю цепочку действий на пользовательском интерфейсе.
Критерий успешности теста обычно один, но по ходу теста можно проверить функционал причастный к фиче по бокам.
Пример - если кто-то комментирует ваш контент то у вас появляется индикатор на соответствующей кнопке.
Можно написать отдельные тесты на то, что он появляется - и иногда это целесообразно делать - а можно включить эту проверку в другой тест, который например проверяет что комментарий доходит и его можно увидеть на соответствующей странице.
Предвещая возражения о том, что подобный подход размывает границы теста могу сказать, что тут все зависит от здравого смысла - если лепить это бездумно и везде, то размоет, еще как размоет.
Мы не даем этому случаться благодаря обучению людей и процессу код ревью.
Таким образом тест у нас проверяет одну точку функционала по одному критерию обычным assert-ом, а ряд дополняющих - с помощью отложенных assert-ов.
Эта техника появилась у нас более года назад.
Аналогичная техника есть в TestNG - там она называется SoftAssert.
Прочитать про нее можно вот тут и тут.
От TestNG мы отказались и их SoftAssert-ами никогда не пользовались, а вот техника прижилась.
Мне очень не нравится слово SoftAssert - ассерт не может быть мягким.
Мы называем это Delayed Assert - ассерт все равно случится и если условие не выполнено тест упадет, но сделает это позже, пройдя через еще пару точек проверки (может быть :)).
Зачем оно надо?
Мы занимаемся интеграционным тестированием, при том тестируем мы не компоненты, а интеграцию целых сервисов.Чтобы это сделать нужно написать полноценный end-to-end тест, который пройдет через всю цепочку действий на пользовательском интерфейсе.
Критерий успешности теста обычно один, но по ходу теста можно проверить функционал причастный к фиче по бокам.
Пример - если кто-то комментирует ваш контент то у вас появляется индикатор на соответствующей кнопке.
Можно написать отдельные тесты на то, что он появляется - и иногда это целесообразно делать - а можно включить эту проверку в другой тест, который например проверяет что комментарий доходит и его можно увидеть на соответствующей странице.
Предвещая возражения о том, что подобный подход размывает границы теста могу сказать, что тут все зависит от здравого смысла - если лепить это бездумно и везде, то размоет, еще как размоет.
Мы не даем этому случаться благодаря обучению людей и процессу код ревью.
Таким образом тест у нас проверяет одну точку функционала по одному критерию обычным assert-ом, а ряд дополняющих - с помощью отложенных assert-ов.
Как оно работает?
Устроено все просто. Механика работы таких ассертов разделена на две части - первая собственно делает проверку и хранит ее результат, а вторая анализирует результаты в заданный момент времени.
Таким образом получается что проверка выполняется немедленно как при обычном ассерте, но выброс исключения - только тогда когда мы считаем нужным - в конце тестового метода.
Проект выложен на гитхабе.
https://github.com/kronar/delayed-asserts
Gist c примером того как оно падает.
https://gist.github.com/392a0f488127f811d7a2.git
Таким образом получается что проверка выполняется немедленно как при обычном ассерте, но выброс исключения - только тогда когда мы считаем нужным - в конце тестового метода.
В натуре
Проект выложен на гитхабе.
https://github.com/kronar/delayed-asserts
Gist c примером того как оно падает.
https://gist.github.com/392a0f488127f811d7a2.git
Комментариев нет:
Отправить комментарий