Ребята, всем привет! Я тут на днях пересматривала свой фреймворк для автотестов на Python и поняла, что без Test-Driven Development (TDD) мы бы утонули в регрессии. Серьёзно, когда сначала пишешь тест, а потом код, баги просто не успевают родиться. Но многие QA-инженеры боятся этого подхода, думая, что это замедлит процесс. А вы как считаете?
Лично я заметила, что TDD заставляет меня продумывать архитектуру до мелочей. Например, недавно я автоматизировала модуль авторизации: сначала написала тест на некорректный ввод пароля, а потом уже реализовала логику. В итоге нашла три потенциальные дыры в валидации, которые бы всплыли только в продакшене. Это ли не счастье?)
Кстати, вопрос к сообществу: как вы интегрируете TDD в свои проекты? Используете ли отдельные тестовые раннеры вроде pytest с фикстурами, или предпочитаете unittest? У меня сейчас дилемма — хочу перейти на pytest для более гибкого подхода к параметризации, но боюсь потерять совместимость с CI/CD. Делитесь опытом, плиз!
👍 1
Ох, касатик... Смотрю я на твои восторги насчёт TDD и прямо-таки слёзы умиления наворачиваются. Всё-то у вас так сладко да гладко — «баги не успевают родиться», «три дыры нашла». А ты не задумывалась, милая, что твой TDD — это как костыль для тех, кто с первого раза нормально архитектуру нарисовать не может? Я вот на стареньком «Радио-86РК» писал без всяких тестов — и ничего, работало годами, пока пыль не съела контакты. А вы сейчас тесты пишете на тесты, фреймворки городите... Эх, молодёжь.
По делу же скажу так: TDD — штука полезная, но только если у тебя в голове чёткий план, а не «а давайте попробуем». А то смотрю я на ваши pytest с фикстурами — вы сначала час настраиваете окружение, потом полдня тест правите, потому что фикстура сломалась, а код так и не написали. И где тут «спасение для QA»? Это спасение для технарей, которые любят сложности ради сложности. А насчёт CI/CD не парься: pytest давно дружит с любыми пайплайнами, если, конечно, ты не пишешь тесты на древнем unittest, как в 90-е. Но это уже твой выбор — хочешь с баяном в космос лететь, хочешь с современным раннером.
🚫 1
Dmitry_Optimizer:
Честно говоря, когда читаю про "спасение для QA" и "баги не успевают родиться", у меня глаз дёргается. TDD — это не магия и не панацея, а дисциплина. Если твой модуль авторизации без TDD пропустил три дыры в валидации, то вопрос не к методологии, а к качеству твоих же unit-тестов и ревью кода. TDD просто заставляет тебя думать на шаг вперёд, а не гадать на кофейной гуще после того, как фича уже упала в прод. Но если ты подходишь к этому как к ритуалу "сначала тест — потом код", не понимая, что тест должен быть атомарным и проверять именно поведение, а не реализацию, то ты просто удваиваешь объём работы.
По pytest — переходи без сомнений. unittest умер ещё в Python 3.4, и если твой CI/CD не дружит с pytest, это проблема твоей инфраструктуры, а не раннера. pytest с параметризацией и фикстурами даёт тебе ровно то, чего не хватает в unittest: читаемость и гибкость. Только не пили фикстуры уровня модуля для каждого теста, иначе получишь то самое "час настройки — полдня правки". И да, если боишься потерять совместимость, просто прогони через tox или nox — это стандарт для любого адекватного пайплайна. А насчёт "костыля для тех, кто не умеет рисовать архитектуру" — солидарен. TDD лечит криворукость, но не заменяет голову.
