Comments 25
Скажите, где живут компании, где всё это практикуется? Я в таких не работал. Наверно для php это редкость.
Всяк сам кузнец своего счастья. Чтобы начать писать тесты, не нужно божественного знамения, специальной компании или специального языка. Просто начните писать.
Просто начните писать.
Не всё так просто. Начать писать - необходимое, конечно, но недостаточное условие.
Чтобы получить
Это когда нажал кнопку и через короткое время, увидев зеленые тесты, точно знаешь, что все работает.
важно, чтобы вся команда писала тесты. И писала качественные тесты, а не отписки для лида, лишь бы отвалил.
Вы представляете ложную дихотомию. Или нет нихрена или вся команда дружно пишет тесты и все автоматизированно. На деле между этими крайностями много всякого. Часть можно делать в инициативном порядке. Никто вас не покарает, если вы для собственного спокойствия начнете писать юниты или интеграционки на свой код. Ну а другие пусть и дальше мудохаются и дебажат на проде, если им так больше нравится.
Как показывает практика, такая деятельность действительно экономически не оправдана.
Если хотите научиться писать тесты, то это всяко лучше чем вообще не писать тесты. Но если хочется получить отдачу от траты времени на написание тестов, то это не вариант.
При существовании ИИ-ассистентов жаловаться , что тесты долго писать - это уже из области юмора.
Я не знаю, каких именно "экономических оправданий" вы ждете, но мне хватает того факта, что если я написал тест на кейс Х, то он точно не стрельнет на проде. Значит меня не будут теребонькать на выходных. Значит компания не понесет издержки. Значит квартальный отчет будет лучше. Значит больше поводов для премии сотрудникам.
Нет, дихотомия не ложная. Судя по
но мне хватает того факта, что если я написал тест на кейс Х, то он точно не стрельнет на проде. Значит меня не будут теребонькать на выходных.
- скоуп разный:) В вашем случае "вся команда" - это лично вы в своей выделенной делянке, в которую никто кроме вас не лезет и из которой вы не вылазите и для которой работает "тесты зелёные - можно в прод":) Так тоже работает, если получается отгородиться от хаоса снаружи.
Но если в проекте нет владения кодом и любой разработчик может править любой код, то либо все пишут тесты, либо получить "Это когда нажал кнопку и через короткое время, увидев зеленые тесты, точно знаешь, что все работает" не получится.
Это, в принципе, редкость, не только для php. Как я писал в статье - таких всего 7%. Есть примеры pivotal, thoughtworks, Google, Amazon и ещё кучи компаний, где к автоматическому тестированию относятся очень серьёзно.
В России таких компаний исчезающе мало. Я видел, что подобным хватаются в додо. Есть ещё редкие компании, где это делают на уровне всей компании. В остальных местах подобные практики выполняются либо на уровне отдельных команд энтузиастов, либо отсутствуют вовсе.
Конкретно про пхп, к сожалению, не подскажу.
Только что узнал кстати, что в SkyEng ребята на PHP практикуют TDD, CD и XP. Там пока открытых вакансий на разработчика не вижу, но, если очень интересно, то рекомендую им написать. Обычно работодатели инициативу ценят :)
Извините. А где, собственно, гайд по автотестам? Я сам разработчик и нахожу в себе силы писать юнит тесты. Иногда практикую ТДД. А так же приходится писать и тесты которые покрывают целый процесс. Но это все надо писать.. ручками, создавать контейнеры данных, сценарии, и в конце нажимать эту самую заветную "кнопку". Как это все автоматизировать? Как сделать автотесты? Кто из генерирует? Какое они имеют покрытие и кто это может отследить?
Автоматизировать часть или полное написание тестов можно через AI, лично практикую на фронтенде с playwright (для конкретного пакета кейсов на больших компонентах). Главное точно описать сценарии тестирования, описать общую стилистику и требования к тестам (пишется один раз навсегда, и мелкими дополнениями время от времени), так же просить писать тест по описанию, но на предварительно изученных других подобных тестов на проекте (подготовка контекста диалога для минимизации ошибок при написании теста).
Это первая часть из цикла. Остальные две части дадут больше ответов. В ближайшие пару недель опубликую и их.
А что значит "пром" в тексте?
Продакшн, рабочая система.
Имеется в виду "прод".
"Development/DEV" система, где идет разработка продукта и исполняются юнит тесты;
"Quality/QAS" система, где тестируется процесс и система, запускаются интеграционные тесты, юзер тесты итд;
"Production/Productive/PROD" система, где уже все работает по настоящему, но и здесь можно провести нагрузочный тест (load test) стресс тест (stress test);
Пром - калька с production environment, "промышленная среда". Используются во всяких банках. Написал по привычке, исправил не везде.
Вот честно. Как начать писать? Как объяснить заказчику, что фича будет поставлена не через неделю, а через две или три, потому что надо писать тесты. А потом ещё их поддерживать.
Как люди пишут интеграционные тесты, тогда модуль А что-то дёргает, ложит в Б, а на экране так вообще 2-3 перехода происходит. Это вам не юниты писать. Тут ещё и анимацию и переходы, и обновления виджетов проверить. Это же просто прорва времени, очень дорогостоящего разраба, который будет писать тесты к этому.
Разраб работает час, тестировщик ещё час. Но это не 100+100 рублей. QA обычно подешевле, и справится могут быстрее. А писать тесты иногда и посложнее кода. И ты это заказчику не объяснишь.
У К. Бека, емнп, есть хорошая методичка по tdd. Меня когда-то мотивировала в начале. Это к вопросу как начать. Заказчику - ну если денег только на такое качество, чтобы потом чинить в полёте, а гарантии работоспособности уровня описываемого в статье не по карману, может и никак)
По моему опыту, без tdd я пишу менее качественный код, и делаю это дольше, тк чаще сворачиваю не туда при проектировании на лету без тестов, дольше отлаживаю. Это про юниты. Поддержки обычно не требуется. Но это с многолетний практикой. В прошлом - сложность освоения парадигмы, смены порядка тесты-код. И грабли, когда поддержка их могла занимать много времени.
Не всякий интерфейс удобно тестируем e2e. Как и код. Если сплошные свистелки, анимации это может мешать. Если есть единый ui, спроектированный как инженерное решение, то он и к автотестированию будет дружелюбные. И в пирамиде между юнитами и тем что вы описываете есть другие градации. Важно понять цель, что, как и зачем целесообразно тестировать - анимацию, модуль, передачу данных, представление на экране или ssr.
В командах смогших в tdd, ddd, xp, не всегда qa отдельный необходим, или работы ему явно меньше будет, чем там, где разработчики на шнурки себе наступают. Но и разрабы сами себя тестами обкладывающие стоят часто как 1 обычный + qa))
И нигде не сказано, что такое "тест" в принципе.
Вот-вот, у нас тут все разработчики ответственно пишут все тесты, я им доверяю, кружочек горит зелёным, поэтому мы спокойно можем разворачивать любую такую версию.
А что мешает доверять разработчикам без тестов вообще и без горящего кружочка?
Более того, на одной из моих работ так и было: все могут добавлять код в основную ветку, никто их не проверяет, нет ни код-ревью, ни тестов написанных разработчиками, а тестировщики единоразово проверяют, что поставленная задача выполнена. И всё работало.
Дело ли в тестах тогда, или, может, в личной ответственности?
Полный гайд по автотестам для лидов и разработчиков. Часть 1