Comments 9
Кроме того, очень важно заранее чётко определить, чего именно мы ожидаем от каждого теста.
Эта пожалуй самая важная строка ибо тесты в основном на дурака делаются.
Изоляция возможна только для простых тестов где можно реализовать не тестируя ибо библиотеки и фремворки уже покрыты тестами. Оопешную бизнес-логику с кучей взаимосвязей без общего контекста нормально не протестируешь.
Статья больше для начинающих, содержит тот же контент которого в избытке в RU& ENG среде. Ни чего ного, ни про pytest, ни про jest, ни про unitest. По крайней мерере я не заметил (или пропустил).
Из всего заинтересовала лишь вот это: "... что особенно важно, писать действительно полезные тесты ...".
Здравствуйте!
>> "писать действительно полезные тесты" :
- Какие критерии (Ваши лично) характеризуют тест как полезный ?
- По каким критериям (Принимающая сторона) принимают тест - как полезный ? Принимающую сторону разобъем на людей которые :
- - разбираются в среде IT?
- - не разбираются в среде IT, которые творческую составляющую бизнеса больше знают чем, то как устроен web?
Ведь мы можем для отчетности, чтоб продать работу CRUD покрыть тестами. Просто, чтоб показать "Вот смотрите, мы покрыли код тестами".
Например.
Из заявленного Вами опыта.
Как Вы охарактерезуете данный https://github.com/Tryd0g0lik/truck_driver/tree/master/__tests__ тест, что его делает полезным или безполезным (если что, то в критике не сдерживаейтесь)?
Спасибо за комментарий. Я и не пытался рассказать про техническую часть в данной статье, может сделаю это в будущем так как надо очень сильно погружаться в эту тему. Может сделаю потом.
Тут я больше хотел рассказать о вещах с которыми я сталкивался на нескольких проектах в которые я приходил разработчиком. Может это будет кому то полезно.
Тест как полезный для меня лично это который максимально проверяет функционал, учитывает корнер кейсы и минимально использует вещи по типу мокирования, вместо это используя более динамический подход. Ну а главное что он действительно что то проверял и ловил если что то сломалось.
Тесты которые вы прислали не плохие. Из пожеланий наверное я б убрал чистку в автоматические фикстуры вместо явного вызова их в методах. И явную проверку что БД действительно создаются строчки и полную проверку ответов.
Ну и на этом спасибо. Относительно моих компонентов.
В fixture убираю :
- дублирующийся код;
- код который надо сделать:
-- до теста;
-- после теста (может где-то и пропустил относительно этих принципов).
Лично моё мнение о mock-ах. С mock-ами зря Вы наверное так. Вы там, что-то говорили - надо выделить идею/цель того "Что тестировать". Вот если их знать, они и помогоют закрыть лишнее, и выделить нужное. Но это моё мнение и ни кого не принуждаю. Так, просто.
Тема скорость выполнения против чистых тестов раскрыта однобоко. Иногда независимостью стоит пожертвовать для скорости.
Порядок запуска тестов лучше объяснять через параллельный запуск.
Согласен, скорость выполнения была не достаточно раскрыта. Может быть потом еще напишу статью с мнением как это можно ускорить, улучшить.
В моем опыта, зависимость тестов приводила к большим проблемам чем лишняя условная минута выполнения тестов. Особенно когда ты пишешь тест на новый функционал а он почему то ломает старый тест. И иди потом разбирайся что случилось =)
На практике намного удобнее тестировать более крупные участки логики без необходимости писать отдельный тест на каждую функцию — они всё равно покрываются в составе общего сценария.
Несколько раз поднимать мок базы, чтобы проверить чистую функцию на разные значения? Дороговато будет.
Ну и некоторые вещи просто не доступны через внешнее апи. Например метод работает со строкой, а в апи ограничение на 100 символов.
Нет, в моем случае база поднимается только один раз в начале тестов а удаляются в конце. Перед каждым тестом создаются таблички в БД, а эта операция достаточно быстрая.
Если важна скорость, то можно сделать один тест который будет проверять чистую функцию на разные значения, просто надо его верно построить. Но это потребует внимательности.
Для меня главное чтоб разные тесты были независимые.
Основы тестирования и правила, которые помогают надёжно тестировать сложные приложения: примеры на Python