Согласен, скорость выполнения была не достаточно раскрыта. Может быть потом еще напишу статью с мнением как это можно ускорить, улучшить.
В моем опыта, зависимость тестов приводила к большим проблемам чем лишняя условная минута выполнения тестов. Особенно когда ты пишешь тест на новый функционал а он почему то ломает старый тест. И иди потом разбирайся что случилось =)
Нет, в моем случае база поднимается только один раз в начале тестов а удаляются в конце. Перед каждым тестом создаются таблички в БД, а эта операция достаточно быстрая.
Если важна скорость, то можно сделать один тест который будет проверять чистую функцию на разные значения, просто надо его верно построить. Но это потребует внимательности.
Для меня главное чтоб разные тесты были независимые.
Спасибо за комментарий. Я и не пытался рассказать про техническую часть в данной статье, может сделаю это в будущем так как надо очень сильно погружаться в эту тему. Может сделаю потом.
Тут я больше хотел рассказать о вещах с которыми я сталкивался на нескольких проектах в которые я приходил разработчиком. Может это будет кому то полезно.
Тест как полезный для меня лично это который максимально проверяет функционал, учитывает корнер кейсы и минимально использует вещи по типу мокирования, вместо это используя более динамический подход. Ну а главное что он действительно что то проверял и ловил если что то сломалось.
Тесты которые вы прислали не плохие. Из пожеланий наверное я б убрал чистку в автоматические фикстуры вместо явного вызова их в методах. И явную проверку что БД действительно создаются строчки и полную проверку ответов.
Согласен, скорость выполнения была не достаточно раскрыта. Может быть потом еще напишу статью с мнением как это можно ускорить, улучшить.
В моем опыта, зависимость тестов приводила к большим проблемам чем лишняя условная минута выполнения тестов. Особенно когда ты пишешь тест на новый функционал а он почему то ломает старый тест. И иди потом разбирайся что случилось =)
Нет, в моем случае база поднимается только один раз в начале тестов а удаляются в конце. Перед каждым тестом создаются таблички в БД, а эта операция достаточно быстрая.
Если важна скорость, то можно сделать один тест который будет проверять чистую функцию на разные значения, просто надо его верно построить. Но это потребует внимательности.
Для меня главное чтоб разные тесты были независимые.
Спасибо за комментарий. Я и не пытался рассказать про техническую часть в данной статье, может сделаю это в будущем так как надо очень сильно погружаться в эту тему. Может сделаю потом.
Тут я больше хотел рассказать о вещах с которыми я сталкивался на нескольких проектах в которые я приходил разработчиком. Может это будет кому то полезно.
Тест как полезный для меня лично это который максимально проверяет функционал, учитывает корнер кейсы и минимально использует вещи по типу мокирования, вместо это используя более динамический подход. Ну а главное что он действительно что то проверял и ловил если что то сломалось.
Тесты которые вы прислали не плохие. Из пожеланий наверное я б убрал чистку в автоматические фикстуры вместо явного вызова их в методах. И явную проверку что БД действительно создаются строчки и полную проверку ответов.