
Комментарии 4
Unit-тесты
Проклятие IT-индустрии. Ну, то есть в идеале - штука-то хорошая: "давайте мы будем тестировать мельчайший контракт отдельным атомарным быстрым тестом". Проблема в том, что это применимо, как правило, только к алгоритмам. Например, функция, которая ищет кратчайший путь на карте. Сделать для нее тест - благое и в целом достаточно простое дело.
Юнит-тесты вполне можно пускать в настоящую базу, и это может очень сильно поднять их полезность. База поднимается in-memory, каждому воркеру своя. Отдельные тесты или сюиты за собой подчищают.
Кто сомневается в скорости: 2400 тестов, 90% которых лезут в базу, прогоняются за 2-3 минуты. Около 50к LOC кода и такой же объём тестов. Отдельно взятый тест прогоняется секунд за 5-10, то есть для активного кодинга и дебпггинга подходит.
И нет, это не интеграционные тесты. Они тестируют поведение отдельных модулей. Я в курсе про религию, которая строго заставляет СУБД мокать и абстрагировать. Но мы такого не исповедуем и рассматриваем её как данность рантайма. Никто же не мокает арифметику, например. Вот и мы жёстко завязались на конкретную СУБД и не стесняемся этого.
Короче кошек надо уметь готовить как всегда.
Согласен, но далеко не всегда можно поднять базу быстро и in-memory.
Я бы сказал дьявол кроется в деталях. Есть большое количество частных случаев и я ничего не имею против. Кошек действительно надо уметь готовить.
Но основной посыл статьи в том что авто тесты делаются по большей части тем кто не умеет.
И моя безопасная рекомендация - идти от REST API (или его аналога), потому что там есть очень четкий критерий хорошо/не хорошо. В остальных случаях - может быть так что тестов много покрытие отличное, но это ничего не значит.
Вообщем просто не понимание процесса разработки.. юниты нужны не только для качества , но и для поддержки кода в будущем, рефакторинг например, да любые изменения в принципе не возможны без покрытия юнит тестами. Есть такой принцип написания текстов FIRST, F-FAST... Такие тесты и него удешевляют разработку, а не стоят дополнительные деньги. Главное в статье спутано покрытие кода и покрытия кейсов использования системы.
Опус о том что показываю сломанные юнит тест , а система работает, показывает просто бездну. Значит работает система не потому варианту , что в тесте, когда пишется код, код и тесты актуализируются. То есть если у вас есть блок мертвого кода, это не значит, что у вас плохие тесты, это значит у вас проблема с процессами разработки.
Опус о невозможности что-то тестить если это Букинг отелей... Тут со дна стучат уже. Ну возьмите вы практически стандарт индустрии: test containers. Или вот есть у вас рест: 400 ошибку. Хотя да.. юнит тесты нужны слабым программистам))
Что мне не нравится в текущем подходе к QAA