Как создать среду, в которой исправление тестов рассматривается как приоритет?

Я инженер-программист в компании среднего размера. У нас есть достаточно надежная платформа тестирования, работающая на TeamCity. Он выполняет юнит-тесты при каждой регистрации и ежедневный юнит-тест / запуск BVT.

Проблема в том, что у нас много сломанных юнит-тестов.

Довольно часто я вспоминаю бессмысленность юнит-тестов, если они постоянно ломаются и не поддерживаются. Отсутствие возможности увидеть, вызвало ли изменение регрессию, приводит к потере большей части ценности платформы модульного тестирования.

Я хотел бы посадить семя, которое создаст культуру хороших привычек - исправление тестов, когда они сломаны, восприятие их как ценных, расстановка приоритетов в тестировании наряду с другой работой.

Я пробовал взяточничество (выпечка!), Просто спрашивал и разговаривал с руководителями команд. Все говорят, что это хорошая идея, но я вижу, что единственный, кто что-то делает с этим.

Каков наилучший способ начать побуждать других к исправлению своих тестов и расставлять приоритеты по исправлению тестов в своих спринтах?

Если есть менее субъективный способ задать это, я был бы рад принять любые советы.

— Codeman
источник

автоматическое оружие нерфа, нацеленное на парня, ломающего сборку ...

— чокнутый урод

У нас на самом деле есть автоматическое оружие нерфа ... но сборка не сломана, только юнит-тесты :)

— Codeman

Прерывание юнит-тестов должно означать нарушение сборки. ;)

— Jeroen Vannevel

@ Ӎσᶎ: бай-ин важен, но вы не можете получить бай-ин для решения проблемы, пока люди не осознают проблему. В этом случае вступительный взнос должен первоначально исходить от руководителей команд и менеджеров. Вклад разработчика может произойти позже и, как правило, произойдет, когда система сборки будет настроена так, чтобы отдельные разработчики платили за свои ошибки.

— Aaronaught

Если пончики не удалось, ты тост. :-)

— Росс Паттерсон

Ответы:

Сделайте так, чтобы на самом деле ничего не выпустить без исправления тестов.

Сбой сборки, если какие-либо тесты не пройдены.
Сбой сборки, если какие-либо тесты игнорируются.
Сбой сборки, если охват тестами опускается ниже определенного уровня (поэтому люди не могут просто удалить тесты, чтобы обойти его).
Используйте CI-сервер для создания своих сборок релиза и разрешайте переводить сборки только из сборки сервера на UAT / staging / production / что угодно.

Дело в том, что если ваша сборка прерывается более чем на 15 минут за раз (и это включает в себя неудачные тесты), то вы не выполняете непрерывную интеграцию .

«Ядерная опция» заключается в том, чтобы ваш сервер управления исходным кодом отказывался от фиксации / регистрации от любого пользователя, кроме того, кто нарушил сборку. Очевидно, что администратор должен иметь возможность временно отменить это, если указанный человек уходит в отпуск - но, если все знают, что вся команда испорчена, пока они не исправят свои тесты, то они решат это чертовски быстро.

Хорошей политикой (которая даже лучше, когда она автоматизирована) является возвращение источника к последней известной стабильной фиксации после 15 минут сбоя сборки. Другими словами, если вы не можете это исправить или не знаете, что привело к сбою сборки или теста, верните его и работайте локально до тех пор, пока оно не будет решено - никогда не заставляйте других разработчиков вертеть пальцами, пока вы не решите проблема, которая их не волнует.

PS Если у вас уже есть много неудачных тестов, вы можете использовать «конечный порог» в CI. Настройте его так, чтобы сборка завершалась неудачно только в том случае, если тестовых сбоев будет больше, чем в прошлый раз. Это, наряду с правилом покрытия, заставит разработчиков в конечном итоге улучшить тестовую ситуацию, если они захотят продолжать работать.

PPS Я понимаю, что некоторым это может показаться суровым, но это все в вашей культуре. Если вы попадаете в точку, когда люди просто не оставляют сборку неработоспособной или тесты не выполняются (моя команда почти никогда не делает этого, хотя мне иногда приходится им напоминать), тогда вам не нужно продолжать соблюдать самый строгий набор правил. Хотя IMO, вы всегда должны проваливать сборку на сломанном модульном тесте Интеграционные / браузерные тесты могут иногда проваливаться.

— Aaronaught
источник

Хотя все ваши технические советы полезны, я думаю, что наиболее ценная часть вашего ответа состоит в том, что «Это вся ваша культура», потому что это не просто проблема дисциплины, это проблема воспринимаемой полезности теста. Я бы лучше положил его на фронт, чем в PPS

— user40989

@ user40989: Я тебя слышу. Культура - это то, что вы должны развивать, хотя. Если вы хотите, чтобы люди понимали, насколько важны тесты, вам иногда нужно сделать так, чтобы люди не могли их игнорировать. Как только люди привыкнут к высокому уровню покрытия кода и экологическим тестам, они не захотят возвращаться, и тогда ваши собственные разработчики будут применять его для новых рекрутов. Ну, надеюсь. Помогает руководитель, сохраняющий анал, и / или мастер сборки и / или менеджер. :)

— Aaronaught

FWIW: Весь наш процесс выпуска теперь автоматизирован, и люди не будут думать о том, что сломали тесты. Руководитель группы выполняет слияние с мастером, затем запускает сборку релиза и отправляет запрос на продвижение системным администраторам, которые буквально нажимают кнопку для развертывания из артефактов сборки и запускают автоматические тесты браузера и API. Никто никогда не жалуется на этот процесс, потому что он экономит время - мы привыкли тратить 2 недели на суету над выпуском, сейчас это в основном ручная волна. Это то, что я имею в виду, взращивая культуру - все знают, что дополнительные 2 минуты для исправления теста сэкономят 2 часа спустя.

— Aaronaught

Тесты модулей, которые не проходят, не являются проблемой. Они являются симптомом .

Настоящая проблема в культуре. Тебе нужно осторожно наступить: здесь будут драконы . Вы не можете изменить культуру самостоятельно, и то, что скрипучее колесо, в конце концов, сделает вас изгоем. Буквально.

Я предлагаю это, если вы попытаетесь найти старшего человека, чтобы защитить дело и проложить путь. Если это не помогло, попробуйте поднять его на общем собрании разработчиков, не указывая пальцами и не называя имен. Другой вариант - взять на себя ответственность за правильную работу: просто исправляйте еще несколько тестов каждый раз, когда вы проходите регистрацию. Держите на стене график, показывающий, сколько тестов со временем провалилось. Другие увидят это: возможно, они согласятся.

Нет простого ответа.

— andy256
источник

Быть скрипучим рулем заставило меня возглавить команду. Может быть, что-то не так с твоим писком? Однако, если серьезно, это говорит о совершенно другой проблеме культуры, не с командой разработчиков, а с руководством компании. Если ответ руководства на горящий огонь состоит в том, чтобы надеть солнцезащитные очки, тогда просто убирайтесь отсюда. Но если вы на самом деле DEV магазин , в отличие от ИТ - отдел предприятия вспенивания программного обеспечения от центра затрат, это довольно вероятно , что менеджеры заботятся о таких вещах , как часто и безопасно вы можете выпустить на рынок.

— Aaronaught