Как стать автором
Обновить

Комментарии 6

Увидев валидацию подумал что будут тесты/статический анализ.
Но их нет, потому добавлю от себя, и ещё эту пикчу:
Cost-per-defect-graph

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


А юниттесты — понятное дело, тоже нужны, и об этом написано много. В том числе и поэтому касаться этого я не стал в статье

Что порекомендуете повесить на препуш-хук для .net бэкенда?

Была идея запускать прогон тестов бэкенда тоже, однако решил отказаться от нее по нескольким причинам:


  • Чем больше проект, тем больше тестов, а значит и больше времени на пуши. К тому же, в своей работе я следую принципу "много тестов не бывает" и других постоянно убеждаю.
  • Когда рефакторим крупные куски кода, то часто бывает так, что разраб коммит и пушит нерабочий код в свою ветку намеренно, чтобы сохранить проделанную работу.

Держать в течение нескольких дней отрефаченный код без возможности его запушить — рискованно тоже по нескольким причинам:


  • Бас-фактор конкретного исполнителя. Никто не сможет подхватить ветку за него.
  • Никто не сможет помочь с рефакторингом параллельно, стянув код с его ветки.
  • Компьютер может выйти из строя в любой момент.
  • In case of fire git commit git push
Немного не в тему, но почему бы и да
Какой на ваш взгляд туллинг на test coverage юнит тестов хорош? Интересны варианты и с интеграцией в VisualStudio и 3rd party на CI например
Какой на ваш взгляд туллинг на test coverage юнит тестов хорош?

Пока что я не занимался настройкой графиков покрытия тестами, однако есть в планах настроить репозиторий так, чтобы при агенты пайплайнов сканировал test coverage проекта, и если он стал ниже определенного уровня, то пайплайн фейлился

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории