TDD, BDD или как вы не падаете после релиза?

Собственно не так давно я столкнулся с проблемой поддержания работоспособности проекта при разработке, ведь каждое изменение может повлиять на сторонние сервисы. Для того чтобы спать спокойно и не боятся деплоев по пятницам приходится писать множество тестов, а самое главное это поддерживать их актуальность и следить за тем чтобы весь функционал был покрыт ими. У нас в компании мы используем TDD для целостности покрытия тестами и благодаря этому у нас не было ни одного роллбека за все время при ежедневных деплоях, но хотелось бы узнать что вы используете для того чтобы поддерживать стабильность своих приложений при разработке и с какими проблемами сталкиваетесь при этом? Может есть адепты BDD который могут поделится опытом?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Разработчикам не надоело 15 лет муссолить эту тему?

Не у всех есть 15 лет опыта за плечами :(

А 15 лет и не надо чтобы понять. Просто никто книги не читает, а если и читает, то не практикует.

p.s. www.amazon.com/...uided-Tests/dp/0321503627

Та то ж ОО — уже не модно. А если серьезно, что есть ещё кто-то кто верит что есть книжка/дядя которая расскажет как все делать правильно?

скільки популярних сервісів з реальним трафіком і аптаймом в хоча б в 99.9% ти підтримував, в яких для такого аптайму достатньо було покриття тестами?

я про такі навіть не чув, якщо чесно. люди пишуть всякі телеметрії, моніторинги, алертинги, а виявляється, достатньо тестами накрити :)

скільки популярних сервісів з реальним трафіком і аптаймом в хоча б в 99.9% ти підтримував
signalfx.com
conductor.com
Популярные бигдата стартапы.
в яких для такого аптайму достатньо було покриття тестами?
Я таких заявлний не делал. Тесты — страховка от ошибок в логике, и enabler для быстрых изменений. Для аптайма нужен мониторинг, алерты, health checks и т.п. SignalFX как раз этим и занимается.

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

Главное правило: то что работает — работает. То есть покрывать тестами шаблонные вещи — глупость. Вплоть до того, что львиную долю тестов альфа-версии просто выбрасывают на рефакторинге. Потому что есть места кода, которые без серьёзного одобрения сверху никто трогать не будет, а кто будет — пойдёт в гарем работать.

Большинство самого востребованного функционала — легче протестировать вручную или высокоуровневыми тестами, нежели выстраивать жуткое дерево низкоуровневых. И это делается тем проще, чем лучше софт разбит на независимые модули. Когда деплой и роллбэк — дешёвые операции, то и тесты покроют процентов 20 кода и этого с головой хватит.

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

IMHO хороший тест — это тот, в котором тестер понимает что он делает и чего от него ждать. Грубо говоря, это большой тест, вовлекающий в себя серьёзный кусок логики и конечно же всю вспомогательную. В идеале — этот тест есть в продакшене, и можно его запустить звонком по телефону, и отослать его лог (кстати, здесь не грех и автоматику приспособить).

львиную долю тестов альфа-версии просто выбрасывают на рефакторинге.
люто плюсую!!

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

BDD (Bug Driven Development)

just kidding

Behaviour DD хорошо работает когда вы пишите мобайл или фронтенд. Вы можете переводить user-story в акцетенс-тест-сценарий. К сожалению, для backend это не применимо, поэтому Spec DD. Этот подход позволяет избежать разсинхронизации между тестами и спецификацией, между компонентами системы.

Очень интересно почему это не применимо для бэкенд? Там как раз достаточно просто ИМХО — АПИ всякие да базу дергнуть. Так же как и фронт-эндный АПИ тестить. Вот UI интеракции так покрывать ИМХО как раз сложнее.

Совершенно не согласен, ибо сейчас участвую в разработке и поддержке системы, которая состоит из компонентов, висящих в облаке и переодически реагирующих на различные поступающие события. Никакого UI, все выполняется на серверах. Так вот, у нас почти полное покрытие BDD тестами практически всех возможных сценариев обработки данных в системе.
Бизнес аналитики пишут story, описывающие корректное поведение в той или иной ситуации, мы соотвественно реализуем корректное описание step’ов. Все работает как часы.

Guess-driven development (GDD) наше все!

А я думала, что GDD — God Driven Development (oh God, please, let it work)

Це більш близьке до Pray-Driven Development) Змінюєш щось у коді і молися, щоб нічого не впало.

Release and pray.
Есть некая грань в размерах проекта за которой не помогает ни CI, ни code review, ни какой то новомодный *DD. И даже длительное ручное тестирование всеми сторонами не спасает. Деплоить в пятницу в нашем случае идея хороша, можно за выходные проверить что приложения хотя бы открываются.

Есть некая грань в размерах проекта за которой не помогает
Так может не надо ее пересекать? Дробить проект, дробить команду, микросервисы все дела.
Деплоить в пятницу в нашем случае идея хороша, можно за выходные проверить что приложения хотя бы открываются.
Идея не очень: В пт еще могут заходить люди. Деплоить надо в сб ... ночью, что в принципе оставляет нам все те же 48 часов на проверку ... и фикс ... и запиливание новой фичи которую забыли включить в релиз.
Менее саркастичная версия: Деплой в пт — это самообман и попытка закрыть про...аный процесс ценой дом нагрузки на сотрудников. Как результат стабильности это не добавит, а вот потерять сотрудников на раз-два.

Вы то сами пробовали эти микросервисы? А сколько-сколько их у вас?
У меня деплой событие не столь частое, что бы это напрягало кого либо. Поработал в эту пятницу/субботу — в следующую не работаешь, как минимум. По крайней мере из за пятничных вечерних деплоев никто не уволился.

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

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

Частые мелкие деплои политически недопустимы

Бывает. Политическое противостояние с Ops или маркетологи буклетики для новой версии не успевают печатать?

Все зависит от процессов в компании ;)

Вы то сами пробовали эти микросервисы?
Ключивое слово было «дробить», микросервисы — это как одно из решений, при том далеко не самое лучшее.
Дробить проект, дробить команду, микросервисы все дела.
 ну и как это поможет в общем случае бороться с возрастанием сложности? Добавлением сложности меж-сервисно/командного взаимодействия? Этот путь помогает решить некоторые проблемы, но другого характера (масштабируемость разработки).
ну и как это поможет в общем случае бороться с возрастанием сложности?
Контроль за изменениями как в спецификациях/функциональности так и в реализации (коде). Возможность «консервировать» некоторые части.

Билд обычно валится на интеграции компонентов, либо других систем, которую ни TDD ни BDD не покрывают, т.к. тестируют компоненты изолированно. Рецепт прост — smoke-тесты, интеграционные тесты + работа QA на тестовых серверах после деплоя. Ну и деплоить в пятницу — ололо, можно выбрать другой день, чтобы успеть зафиксить.

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

а как же функциональное тестирование?

Чем E2E не функциональное тестирование?

это почему же BDD расценивается как тест в изоляции ??? ... они как раз integration и даже чаще acceptance

TDD — упрощает процесс разработки тем, что уже на этапе тестов вы проработываете и исправляете архитектуру вашего кода с прицелом на тестирование. Если делать наоборот, сначала писать код, а потом тесты, то это все может закончиться магией на моках с тестированием приватных методов и (не дай бог) полей. BDD — странная вещь, иногда требующая серьезных допилов перед тем, как аналитики смогут писать сценарии. Я бы смело ее выбрасывал, если у вас в команде работают автоматизаторы. Тесты без CI в командной разработке имеют мало смысла, так как должна быть единая система, которая делает сборку кода, запускает Тестовые Сценарии на альтернативном окружении и делает автодеплой мануальщикам. Разговоры а у меня на компе все работает — больше не проканают :) Под Тестовыми Сценариями я имел в виду очередность, когда запускаются сначала самые легкие тесты(юнит), если они проходят, только тогда интеграционные тесты. Но не наоборот. Тесты и тестовые сценарии нужно продумывать для того, чтоб не делать двойного тестирования одной и той же логики и притом иметь возможность создавать целые тестовые зависимости и опять же, сценарии. Нагрузочное тестирование и регрессию делают QA, вам об этом не всегда нужно знать:)

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

мы используем TDD для целостности покрытия тестами и благодаря этому
Плохая новость: не благодаря этому.
ТДД — это не решение, его использование просто коррелируется с профессионализмом разработчика/команды.
Может есть адепты BDD который могут поделится опытом?
БДД по сути своей то же что и ТДД, просто ориентированое не на программиста, а на бизнес.

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

залежно від задачі і визначення «не падити» (для когось це означає «замовник не пише — все ок», а для когось аптайм 99.999%) це може бути:

*тести (від юніт до ui тестів)
*активний моніторинг сервісів (тобто сервіси які активно перевіряють інші сервіси, а не хтось втикає в монітор на cpu usage)
*пасивний моніторинг на основі даних телеметрії (включає в себе системні каунтери)

всякі CI, стабільні бранчі, ніяких деплоїв по п’ятницях і тд — це само собою

ще допомагає ownership + code reivew. тобто в модулів є овнери і вони мусять дати sign off для будь-якого коміту в модуль

срібної кулі немає, працює тільки коли все в комплексі

Насчет не падать — имелось ввиду чтобы пользователи не заметили ;)

Тесты само собой: unit, it и e2e. Но проблема того чтобы доверять им, ведь не факт что кто-то до тебя покрыл все кейсы. ТДД это как выход из этого но опять-же, человеческий фактор остается.

Ну скажем так, new relic помогает узнать что все пропало, но иногда его пролагивает, и он просто перестает считать статистику.

Но проблема того чтобы доверять им, ведь не факт что кто-то до тебя покрыл все кейсы.
en.wikipedia.org/wiki/Mutation_testing

И что помогает? Ведь все равно покроет только в рамках мутации предусмотренной писателем теста. ИМХО «silver bullet» для тех кто не хочет/не может проанализировать значимые точки в данных. Впрочем с интересом услышу другое мнение.

Я сейчас на текущем проекте внедряю:
1. юнит тестирование
2. модульную разработку
3. ночные билды
4. прогон тестов на билд сервере
5. деплой раз в две недели.

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

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

Підписатись на коментарі