Комментарии 6
Увидев валидацию подумал что будут тесты/статический анализ.
Но их нет, потому добавлю от себя, и ещё эту пикчу:
Но их нет, потому добавлю от себя, и ещё эту пикчу:
Cost-per-defect-graph
0
Статья действительно не о тестах, а о том, как подготовить репозиторий для команды, чтобы она стала писать код в одном стиле без просьб и пряников с кнутами. Сама система не даёт написать нестандартный код.
А юниттесты — понятное дело, тоже нужны, и об этом написано много. В том числе и поэтому касаться этого я не стал в статье
0
Что порекомендуете повесить на препуш-хук для .net бэкенда?
0
Была идея запускать прогон тестов бэкенда тоже, однако решил отказаться от нее по нескольким причинам:
- Чем больше проект, тем больше тестов, а значит и больше времени на пуши. К тому же, в своей работе я следую принципу "много тестов не бывает" и других постоянно убеждаю.
- Когда рефакторим крупные куски кода, то часто бывает так, что разраб коммит и пушит нерабочий код в свою ветку намеренно, чтобы сохранить проделанную работу.
Держать в течение нескольких дней отрефаченный код без возможности его запушить — рискованно тоже по нескольким причинам:
- Бас-фактор конкретного исполнителя. Никто не сможет подхватить ветку за него.
- Никто не сможет помочь с рефакторингом параллельно, стянув код с его ветки.
- Компьютер может выйти из строя в любой момент.
- In case of fire git commit git push
0
Немного не в тему, но почему бы и да
Какой на ваш взгляд туллинг на test coverage юнит тестов хорош? Интересны варианты и с интеграцией в VisualStudio и 3rd party на CI например
Какой на ваш взгляд туллинг на test coverage юнит тестов хорош? Интересны варианты и с интеграцией в VisualStudio и 3rd party на CI например
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как не пропустить невалидный код в репозиторий