В одном из выступлений, я тут кидал ссылку, автор linq (.NET) говорит что TDD для pussies :) Нет нигде абсолютной правды, блог именно про это.

о, Алексей, разобрался с телеграмом значит?))))

В одном из выступлений, я тут кидал ссылку, автор linq (.NET) говорит что TDD для pussies :) Нет нигде абсолютной правды, блог именно про это.

А что для нормальных пацанов? Расставить образа, помолиться и в бой? И так при каждом изменении?

Спросите у автора выступления

Тут надо сначала дать определение, а то под TDD каждый имеет в виду свое

Зачем мне за него отдуваться :]

Если TDD = test first, то тут все не очень очевидно. Если же покрытие кода юнит-тестами, то холивары уже в прошлом

воу-воу

TDD != TFD

Да вы акцентируете внимание не на том

Не в магических словах дело

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

но можно решать одни и те же задачи

TDD != TFD

https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

TDD != TFD

Вот, кстати, интересно послушать чем отличается. Я много раз слышал, что TDD != TFD, но в чем разница так до конца и не понял

по слов бывших коллег - и TDD, и TFD это когда ты в начале пишешь тесты, а потом под них код. Лично я сильно против этой практики ибо жизнь слишком сложная штука и часто надо переделывать половину сделанного продукта. И получается, что ты большую часть автотестов выбрасываешь в трубу. Сейчас как раз нахожусь в поиске адекватной модели. Мы сейчас пишем автотесты в спринте. DoD для юзер-стори содержит и автотесты, и выкатку в бой. И мы уже не раз столкнулись с тем? чт

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

по слов бывших коллег - и TDD, и TFD это когда ты в начале пишешь тесты, а потом под них код. Лично я сильно против этой практики ибо жизнь слишком сложная штука и часто надо переделывать половину сделанного продукта. И получается, что ты большую часть автотестов выбрасываешь в трубу. Сейчас как раз нахожусь в поиске адекватной модели. Мы сейчас пишем автотесты в спринте. DoD для юзер-стори содержит и автотесты, и выкатку в бой. И мы уже не раз столкнулись с тем? чт

ну кстати, чтобы не выбрасывать половину тестов с кодом при рефакторинге лучше конечно atdd, вместо просто юнит-тестов.

Для веб сервисов все просто - тесты API с фикстурами в БД, + е2е тесты с моками на фронте + селениумы на критичный и самый важный функционал. Юнит-тесты при это не очень нужны (в классическом понимают юнитов).

1) я к сожалению не понял что написано, но хочу понять (я product owner) 2) мы сделали изменение фронта очень серьёзное и это потянуло за собой переделку автотестов, но в беке (java, rest) ничего не изменилось с автотестами

1) я к сожалению не понял что написано, но хочу понять (я product owner) 2) мы сделали изменение фронта очень серьёзное и это потянуло за собой переделку автотестов, но в беке (java, rest) ничего не изменилось с автотестами

Скорее всего речь про селениум-based тесты - с ними все тяжело - они хрупкие, долгие и тяжелые в обслуживании. Да, при рефакторинге ui они сломаются, если были плохо прописаны css cелекторы и если поменялась логика кто куда кликает. Тут поможет только итеративная разрабока и сразу же параллельно покрытие тестами.

Ну и вообще, если код пишется СРАЗУ с тестами, это обычно решает проблему. Написание тестов постфактум, после разработки - практически никогда не взлетает.

У нас в пределах спринта. Написали код, потом код-ревью, потом автотесты.

> Лично я сильно против этой практики ибо жизнь слишком сложная штука и часто надо переделывать половину сделанного продукта. И получается, что ты большую часть автотестов выбрасываешь в трубу. True story

Скорее всего речь про селениум-based тесты - с ними все тяжело - они хрупкие, долгие и тяжелые в обслуживании. Да, при рефакторинге ui они сломаются, если были плохо прописаны css cелекторы и если поменялась логика кто куда кликает. Тут поможет только итеративная разрабока и сразу же параллельно покрытие тестами.

Наш лид говорит, что мы прописываем CSS селекторы и стараемся чтобы они не ломались (и да, у нас селениум-based тесты)

А вы знаете что на самом деле ломается у ваших пользователей?

Степан?

Без непосредственно их обращений

Это ключевое, а не наличие тестов

http://martinfowler.com/bliki/TestPyramid.html

Обращений по этому конкретному продукту пока что 0. Но теперь думаю поставить это в мониторинг.

Наш лид говорит, что мы прописываем CSS селекторы и стараемся чтобы они не ломались (и да, у нас селениум-based тесты)

А у нас имена в css-стилях автоматически генерируются через имя+хэш для уникальности, например.

Не в обращениях дело

Этот продукт пока на очень маленькой группе юзеров

Еще раз - надо значть что продукт ломается на клиенте

Ну тогда и вопрос с тестами не должен стоять, если вы на этом этапе а они вас тормозят

Знать что ломается на клиенте, это sentry, airbrake и другие продукты, которые реально помогут вам понять что у пользователя случилась ж...а :)

а не TDD

не спорю

у нас за этим следят DevOps-ы

у нас миллионы пользователей и без автотестов никак

Это вы сейчас так системных администраторов обозвали?

:]

Слав, давай на ты :) и нет, это полноценная команда DevOps

Автотесты - замечательно, но если ошибки не регистрируются на сервисе с миллионами пользователей, тесты - лишь иллюзия

А что такое полноценная команда ДевОпс, они продукт пишут?

В компании либо все девопс, либо нет девопс

В компании либо все девопс, либо нет девопс

👍

Какой-то абсолютизм :) предлагаю не спорить. Всех деталей я не знаю (и не могу рассказывать). Но с большим интересом послушаю мнение более умных людей чем я :)

Проблема с терминологией

Дело не в споре, мы ж не спорим что 2x2=4 :]

больше/меньше уделять время на тесты - это в принципе функция от риск, риск надо померить, например посмотреть графики ошибок

без привязки к ним это все вера

в лучшее

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

У нас вот есть agile-разработчик, а вот не agile %))

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

Которые в принципе если хорошо протестированы, митигируют многие проблемы

Второй момент - это ограничения платформы / библиотеки. На опыте если поменять одну библиотеку на другую можно существеннее снизить проблемы конечных пользователей.

25-го января в 19:00 пройдет настольная Scrum игра в Бизнес-Инкубаторе Ингрия (Санкт-Петербург). Игру проведет Agile эксперт Джафаров Дмитрий, являющийся одним из авторов игры. Игра проходит при поддержке фонда PiRL Ventures и школы Product.Vision . Настольная Scrum игра разработана школой Product.Vision в 2016 году. Игра предназначена для всех, кто активно интересуется Scrum вне зависимости от имеющейся специализации. В ходе игры участники ознакомятся со Scrum процессом, ролями, артефактами, а так же основными паттернами. Спешите зарегистрироваться на https://www.meetup.com/SPB_AgilePeople-RU/events/237062674/ — количество мест строго ограничено! До скорой встречи на митапе! PS: отличный вечер, много полезных инсайтов и новых знакомств гарантированы! Присоединяйтесь к нам на Telegram, FB, Twitter и Instagram: https://telegram.me/agilepeople https://www.facebook.com/agilepeople https://twitter.com/agilepeopleru https://www.instagram.com/agilepeopleru

>Джафаров Дмитрий >Dmitry Dzhafarov 🤔

>Джафаров Дмитрий >Dmitry Dzhafarov 🤔

сам себя не похвалишь, никто не похвалит тебе ли не знать 😉

ну я то это делаю иронично ( ͡° ͜ʖ ͡°)

ну я то это делаю иронично ( ͡° ͜ʖ ͡°)

кто как умеет ¯\_(ツ)_/¯

сам себя не похвалишь, никто не похвалит тебе ли не знать 😉

-)) да!

Всем пятницы! А есть здесь консультанты по agile, да и вообще консультанты, с кейсами по поддержки стартапов при акселераторах, бизнес-инкубаторах?

Всем пятницы! А есть здесь консультанты по agile, да и вообще консультанты, с кейсами по поддержки стартапов при акселераторах, бизнес-инкубаторах?

Я с трудом понял вопрос, а что конкретно интересует?)

У меня вот стартап, но не в акселераторе, это не считается?

У меня вот стартап, но не в акселераторе, это не считается?

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

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

А А акселератор не причём? Если нет, то я коучил так как-то компанию

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

У цеха вроде свои собственные коучи есть А остальные обычно с крупняком работают..

#whois Всем привет, меня зовут Ник Вицинский, PO в Пражском офисе NCR Corporation (опыт в QA (от Engineer до Head of Department/Manager, сертифицированный Scrum Master, PO, PM, Conversion Manager). До этого работал как в крупных компаниях (контрактор на Reuters, Thomson Reuters, Intuition Publishing) так и в небольших компаниях начиная с gambling, заканчивая creative и крупными e-commerce площадками. Использую скрам, канбан, скрамбан, а также любые другие методологии и подходы позволяющие удовлетворить нужды проекта/продукта/команды/заказчика/ Инструменты - любые, это инструменты. С удовольствием буду делиться своим опытом и знаниями, а также учиться и получать опыт. Также готов к работе удаленно (пока еще есть слоты свободного времени) Originaly from Moldova, но сейчас в Праге, в целом не привязан к локации к месту. Про группу узнал из канала @products_ru

Подписка на #whois

У цеха вроде свои собственные коучи есть А остальные обычно с крупняком работают..

Подождем остальных ))

А вообще такая практика в мире есть, чтобы agile-коучи были при акселераторах?

Программа 3 месяца, там не до коучей :)

Даже если 6

Почему не до коучей?

Потмоу что там менторы из бизнеса и бизнес задачи ?