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