потому что юнит тесты это для программиста

то она должна понимать профит

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

а ты начал разводить

тут прикол в том что задачки в духе "хорошо ложится на юнит тесты" придумать проблемы не составляет

как и собственно тестами такие штуки покрывать

но есть куда более интересные кейсы которые не столь очевидны - и именно задачки подобного рода мне и нужны

например задачки где надо параметризованные тесты, property based testing

работа с тетьими сервисами или изоляция инфраструктуры

вот таких задачек надо

ок тут я подсказать не могу

пора пиздовать спать

что бы люди научились выбирать что покрывать юнитами, что интеграционными, а что еще как

так надо просто начать их писать

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

запись то будет? :D

и как получится пофиг потом улучшите

так надо просто начать их писать

их придумать надо для начала

и как получится пофиг потом улучшите

хреновый план

с точки зрения бизнеса

запись то будет? :D

нет

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

юнит тесты нужны разрабам в первую очередь и больше никому

нет

а потом жалуетесь, что те кто к вам приходят не умееют в тесты)))

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

не надо их бизнесу продавать

если еще e2e как ты называешь можно толкнуть бизнесу типо повторение действий и экономия что толпа обезьянок не нужна

юнит тесты нужны разрабам в первую очередь и больше никому

а теперь попробуй то же но в контексте аутсорс разработки

это нужно только вам

если нужно делаете

ну то есть у тебя есть бизнесы: 1. конечный заказчик, стэкхолдеры и т.д. 2. твоя компания которая занимается разработкой

бизнесу и первой и второй компании юнит тесты не нужны

они нужны разрабам второй компании

1. - им не надо знать про юнит тесты и т.д. Им надо что бы фичи внедрялись быстро. 2. - им надо что бы клиент был всегда хэппи, что бы небыло проблем с управлением ресурсами, что бы на проект можно было закинуть нового челика, и он не зафакапил все.

и это печальный факт юнит тестов

ты как-то примитивно мыслишь

юнит тесты - это средство. Как CI сервер или git

ты ж git не продаешь

да

именно

а теперь смотри, есть всякие continious delivery

поэтому бизнес сюда приплетать не стоит

которые бизнесу ой как могут быть нужны

поэтому бизнес сюда приплетать не стоит

это я к твоему высказыванию "пусть пишут тесты а там как пойдет"

представь что отдел бэкэнд разработки аутсорс компании - это тоже бизнес

наши цели как маленького бизнеса:

ты ж git не продаешь

многие разработчики жалуются что не могут продать бизнесу тесты, у нас есть отличный лайфхак, мы их не продаем (c)

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

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

документация - хэндлится приемочными и юнит тестами. Для CI/CD тебе необходима отлаженная пирамида тестов

если "пишем тетсты как придется а потом будем раскхебывать", то что мы получаем: - расходы времени на разработку повышаются существенно (в 2-3 раза) на начальный период (где-то пара месяцев). - качество тестов без четкого общего вижена может оставлять лучшего и использовать их как документацию может уже не получиться

потому вместо такой вот спонтанности следует выробатать стратегию, как ты будешь внедрять ту или иную технику

в плане управления ресурсами есть еще техники вроде парного программирования

эти штуки тоже никто никому не продает - это внутренняя кухня

слишком много "умных" слов типо вижен и тд

http://macode.ru/

но я надеюсь ты меня немного хотя бы понял

Что говорят менеджеры?

Качественные продукты

Что им нужно на самом деле?

100% покрытие кода юнит-тестами

Что мы делаем в итоге?

ясно

ты не понял

Мы пишем код блять!

я тебя понял

но вопрос получения вижена вещь очень расплывчатая

но вопрос получения вижена вещь очень расплывчатая

если оставлять все на самотек - то да

и может оказаться что вы потратите время на получения вижена

и его не получите

потому что нет критерия, получен ли вижен

это субьективно

то что это субъективно не значит что критериев нет

этим и хороши штуки типа воркшопов, подкрепленных код ревью

ок есть критерии

код ревью да

воркшопы позволяют команде в контролируемых условиях "попробовать" штуки

но опять же пока его проводят люди у которых одинаковый вижен

код ревью предоставляет контроль

которых достаточно чтобы ревьюить код

а еще есть статистика регрессий, кучи метрик из джирки

а еще есть статистика регрессий, кучи метрик из джирки

при условии что таски корректно заводятся и закрываются

но опять же пока его проводят люди у которых одинаковый вижен

потому первый этап плана - синхронизировать вижен у трех человек в команде.

ты правильно говоришь

я не спорю

при условии что таски корректно заводятся и закрываются

допустим условие соблюдается

нам для наших "высших целей" интересует скорость продвижения тасок по борде

от "backlog" до Done

и статистика багов + регрессий

нам для наших "высших целей" интересует скорость продвижения тасок по борде

эта проблема у всех

есть еще всякие рут кос анализы, ретроспективы

канбаны и прочие техники для саморефлексии команды

тренинги

у нас канбан хотим

и cd

но все через жопу

а какой именно канбан?

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

а я хз, вот синхронизация вижена будет как приготовят и расскажут

и есть канбан как способ оптимизации текущего процесса

типо у нас сейчас есть спринты

и сроки спринтов