Это не защита от дурака, это защита от человеческого фактора.

но это их личные половые трудности

Нет, это проблема команды и проекта.

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

ни разу за все время не отправил письмо на бой когда тестировал сервис :) ЧЯДНТ

А потом выходят статьи типа "DodoPizza случайно списала у клиентов 10 млн. рублей, запустив тестовый код"

Да, а в Гитлабе никто никогда не дропал базу случайно.

До недавнего времени.

грустно им

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

!!!

Это прям 1 в 1 обсуждаемый кейс :D

переносить тестовую базу в прод - у них что, бэкапы сломались? XD

недавно было 5. Потом в статье читал 8. Сейчас уже 10. Чувствую, к концу года Додо пицца потеряет и вернёт 100 миллионов.

это вообще не тот кейс, флоу данных вообще другой

Реальные данные -> бэкап -> (optional: миграции) -> тестовый дамп

переносить тестовую базу в прод - у них что, бэкапы сломались? XD

Да там походу тоже неизолировано было

если они накатывали тестовый дамп на прод - это фундаментально не проблема (optional миграций или модификаций тестовой БД) , т.к. пропущен шаг бэкап-баз

Да там походу тоже неизолировано было

https://habrahabr.ru/company/yamoney/blog/325762/

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

Еще я лично знаю пример когда из-за флага неправильной среды --env=prod вместо --env=test на проде был потерт весь кеш elastisearch под хайлоадом и его пришлось срочно переиндексировать

поэтому я завожу cmd alias и всегда жму его и тоьлко его :3

Special cases aren't special enough to break the rules.

sounds like you can add some agility to your rules, brah

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

исключить человеческий фактор все равно не получится, по моему опыту. Поэтому нужно действовать по ситуации, и делать так как эффективнее/лаконичнее/удобнее/лучше для проекта

мб это пиар-акция пиццерии?)

да тут уже второй месяц таких пиар акций. Сначала гитлаб, потом ec2

Приведу такой пример: ты можешь придумать систему, которая будет разворачивать коммит разработчика, который в Dev закоммитил и что-то сломал, и придумать как бы побыстрее это узнать, берешь по коммиту приделываешь смоук-набор. И думаешь, вот круто-то

А круто - это когда разработчик прежде чем говно лить в Дев - запустить сам руками твой тестсьют.

Пример того, как практика != автоматизация и в данном случае лучше, чем попытка за счет усилий андроидов make software great again

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

Круто: когда разработчику не нужно об этом думать

должен кто-то четвертый прийти со своим круто %)

Потому что есть более полезные способы использовать их когнитивные ресурсы

Не вижу ничего плохого в том, чтобы разработчик запустил тесты и увидел как оно отработало. Я не считаю, что разработчик - это божество в вакууме, которое не должно пытаться хотя бы думать в рамках "кому нужен этот код? чью проблему он будет решать? какие могут быть кейсы?" - я работал с разработчиками, которые сами хотели знать, как их код должен работать хорошо. Это и есть когнитивные ресурс и лучшее, как может писать разработчик.

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

возможно, это все можно назвать словом Shift Left.

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

куча таких мест

лол, да ладно?)

я сам разработчик) просто в вашем чатике сижу из любопытства) у нас тех кто не пишет unit тесы, не уважают

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

сколько записей в трудовой в it-сфере, стесняюсь спросить?)

куча таких мест

+++

сколько записей в трудовой в it-сфере, стесняюсь спросить?)

а количество имеет значение? скажу за java тусовку, как уже сказал ранее, кто не пишет unit тесты того не уважают

+++

значит мне повезло не работать в таких компаниях

а количество имеет значение? скажу за java тусовку, как уже сказал ранее, кто не пишет unit тесты того не уважают

конечно имеет. выборка из одного проекта нерепрезентативна например. А то что из тусовки пара человек высказали мнение про юнит-тесты, то это вилами по воде

конечно имеет. выборка из одного проекта нерепрезентативна например. А то что из тусовки пара человек высказали мнение про юнит-тесты, то это вилами по воде

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

Не вижу ничего плохого в том, чтобы разработчик запустил тесты и увидел как оно отработало. Я не считаю, что разработчик - это божество в вакууме, которое не должно пытаться хотя бы думать в рамках "кому нужен этот код? чью проблему он будет решать? какие могут быть кейсы?" - я работал с разработчиками, которые сами хотели знать, как их код должен работать хорошо. Это и есть когнитивные ресурс и лучшее, как может писать разработчик.

Женя, ты немного путаешь. О том, зачем нужен код, какую проблему он решает и какие кейсы могут быть разработчик _должен_ думать. Запускать тесты, прежде чем что-то выливать (как и минимально проверять работспособность фичи любыми другими методами) - тоже. Это его работа, он за это получает деньги, а не за код. QA получает деньги за то, что бы создавать все необходимые инструменты и условия для обеспечения качества продукта. В частности, удобные инструменты для того, что бы разработчики не должны были думать, какие тест-сьюты им надо запустить, что бы их код был проверен. Или что бы они не были вынуждены держать в голове какие косяки тестового контура могут быть в окружении, а сосредоточились на решении проблем и поставке их на продакшен.

сколько записей в трудовой в it-сфере, стесняюсь спросить?)

на трех работах не было людей, не пишущих юниты. что я делаю не так?

ERROR: S client not available

на трех работах не было людей, не пишущих юниты. что я делаю не так?

Экстраполируешь.

На три проекта, на которых разработчики пишут юниты, приходится три сотни тех, где вообще никто их не пишет, и ещё десяток таких, где все считают, что тесты должны писать тестировщики. Sad but true.

На три проекта, на которых разработчики пишут юниты, приходится три сотни тех, где вообще никто их не пишет, и ещё десяток таких, где все считают, что тесты должны писать тестировщики. Sad but true.

интересно, как они рефакторят без юнитов :)

(никак?)

интересно, как они рефакторят без юнитов :)

Есть два варианта: 1) Никак 2) Болезненно.

Один часто перетекает в другой.

Юниты особо и не помогают рефакторингу

Если я удалил какой-то класс то и все тесты на него тоже снесу

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

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

ну а у много кого – часто :)

Просто надо сразу писать идеальный код, как я.

Просто надо сразу писать идеальный код, как я.

абсолютно согласен, к этому стоит стремиться! :)

Только давайте обойдемся без шуток про гуфа

про мёртвых не шутят, да.

а он что ...?

На три проекта, на которых разработчики пишут юниты, приходится три сотни тех, где вообще никто их не пишет, и ещё десяток таких, где все считают, что тесты должны писать тестировщики. Sad but true.

Это не разработчики, а кодеры

Это не разработчики, а кодеры

Ну, это не только от разработчиков зависит, так то, но да, на большинстве из них сидят кодеры, а не разработчики, и тестеры, а не QA.

Весна пришла... Тестировщики созрели...

оттаяли*

Нет, это один человек

И зачем ему два аккаунта?

Предлагаю спросить у него в личке, а не обсуждать это здесь.