Моделирование на примере: общее понимание

Кросс-пост от Середина; Первоначально опубликовано 7 апр. 2017 г.

Я недавно посетил PHP Великобритания 2017 конференции в Лондоне. Помимо того, что я узнал, что PHP составляет 82% веб-сайта, я также увидел удивительный доклад Киаран МакНалти (@ciaranmcnulty) называется Управление дизайном на примерах (слайды являются хорошим ориентиром, и вы также можете увидеть видео разговора).

Примечание. Хотя эта статья конкретно относится к PHP, принципы можно применить к любому типу разработки (просто замените их соответствующими инструментами).

Отказ от ответственности: это краткое изложение выступления с некоторыми моими личными интерпретациями и мыслями. Любые ошибки на моей совести.

Моделирование на примерах сочетает в себе некоторые концепции разработки, управляемой поведением (BDD), и проектирования, управляемого предметной областью (DDD). —Константин Кудряшов (@everset).

Развитие, основанное на поведении

«BDD — это искусство использования примеров в разговорах для иллюстрации поведения» —Лиз Кио.

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

Приведем пример. Ну, вообще-то, давайте просто украдем пример Кьярана…

Каждый фунт стерлингов, потраченный на перелет, приносит 1 балл.
100 баллов можно обменять на 10 фунтов стерлингов на будущий рейс.
Полеты облагаются налогом в размере 20%

Не знаю, как у вас, а у меня, глядя на эти требования, возникает несколько вопросов.

Вы зарабатываете баллы за налог или только за базовый полет?
Можно ли зарабатывать баллы, когда вы их используете?
Можете ли вы выкупить более 100 баллов за раз, если они у вас есть?
Если вы обмениваете баллы, с какой суммы вы облагаетесь налогом?
Мне также интересно, если баллы округляются в большую или меньшую сторону при частичной сумме, вы зарабатываете частичные баллы? (По-видимому, стандарт для этого — округление в меньшую сторону)

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

При условии, что конкретный рейс стоит 50 фунтов стерлингов:

Если вы платите наличными, это будет стоить 50 фунтов стерлингов + налог в размере 10 фунтов стерлингов, и вы заработаете 50 новых баллов.
Если вы полностью платите баллами, это будет стоить 500 баллов + налог в размере 10 фунтов стерлингов, и вы получите 0 новых баллов.
Если вы заплатите 100 баллами, это будет стоить 100 баллов + 40 фунтов стерлингов + налог в размере 10 фунтов стерлингов, и вы получите 0 новых баллов.

Теперь вы можете создавать свои сценарии в рамках подготовки к разработке этой функции. Огурец вполне подходит для этого, так как это формальный язык для примеров, но вам не нужно его использовать. Еще одна вещь, которую следует отметить, это то, что сценарии существуют для создания общее понимание функции, чтобы дать первоначальное определение готовности и указать, как тестировать функцию; это не контракты, и они могут эволюционировать по мере того, как вы приобретете больше знаний и понимания. Но нужно с чего-то начинать. Самое лучшее в написании таких сценариев — это то, что они избегают каких-либо деталей реализации (таких как нажатие кнопок и загрузка страниц), которые не должны быть частью теста.

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

Дизайн, управляемый Доманом

«DDD решает проблему сложности, концентрируя внимание команды на знании предметной области» —Эрик Эванс.

Важно потратить некоторое время на понимание бизнеса. Создайте словарь домена, вездесущий языка общая манера говорить о бизнес-концепциях. Это уменьшит стоимость перевода, поэтому разработчик знает, что если он называет объект полетом, то бизнес-эксперт будет точно знать, что это означает в контексте бизнеса. Используйте этот язык при создании своих примеров.

Сочетание аспектов этих двух парадигм дает вам Моделирование на примере.

Моделирование на примере

«Встраивая Ubiquitous Language в свои сценарии, ваши сценарии естественным образом становятся моделью предметной области» —Константин Кудряшов (@everset).

Принципы моделирования на примере:

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

Модель предметной области — это не код или диаграмма. Это общее понимание вся команда (разработчики, тестировщики и бизнес) имеет представление о том, как работает система. Код, тесты и документация — все это представления модели предметной области.

Теперь вы, возможно, слышали о тестовая пирамида (противоположность тому, что это рожок мороженого или кекс— плохо для проекта, но тем не менее вкусно). Идеальным является убедиться, что ваш проект не перегружен медленными тестами, которые легко ломаются; все ненавидят ждать, пока запустится набор тестов только для того, чтобы тест случайно сломался из-за сбоя в сети или чего-то, что не удалось отобразить.

Тестирование каждого сценария через пользовательский интерфейс (UI) является медленным, ненадежным и требует одновременного проектирования предметной области и пользовательского интерфейса. Есть также проблемы с тестированием каждого сценария с реальной инфраструктурой, например, тестирование бизнес-модели может привести к 1000 тестам, которые находят объект по его идентификатору (после одного теста мы можем быть уверены, что он будет работать), а не тестирование интересных пограничных случаев.

Что вы можете сделать, так это сначала протестировать модель предметной области (средний бит) с помощью Behat с поддельной (в памяти) инфраструктурой и запустить код непосредственно из написанных вами сценариев.

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

В примере с авиакомпанией мы начали с использования следующего:

Given a flight costs £50

Добавив реалистичные примеры, мы получили:

Given a flight from "London" to "Manchester" costs £50

Активный поиск терминов из домена и выяснение того, как на самом деле работает бизнес, это превращается в:

Given a flight "XX-100" flies the "LHR" to "MAN" route
And the current listed fare for the "LHR" to "MAN" route is £50

Теперь это дает нам то, с чем мы действительно можем работать. Нам не нужно делать никаких предположений о том, как работает система, и когда мы говорим о проекте с вовлеченными людьми, все будут на одной волне. Если вы не чувствуете, что у вас есть ответы на все вопросы, вернитесь и спросите. Ваш код станет от этого лучше, как и продукт.

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

Просто делайте это шаг за шагом. Начните с первой строки. Создайте ожидающий пример, затем добавьте код только для этого примера.

Смоделируйте все свои ценности как Ценные объекты

Это дает вам больший контроль над вашими данными и позволяет более строго типизировать и проверять. Вы можете использовать@Transform в Behat, чтобы преобразовать ваши строки в правильный формат (новая вещь, о которой я только что узнал), что действительно полезно. Кроме того, вы получаете более аккуратный и читаемый тестовый код, что является несомненным плюсом!

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

Отойдите от набора Behat и начните описывать нужные вам объекты с помощью PhpSpec (или любой другой предпочитаемый вами метод модульного тестирования). Я действительно рекомендую PhpSpec, потому что он переключает ваше мышление с «тестирования» кода на «описание» функциональности; и, на мой взгляд, приводит к гораздо лучшему (и компактному) коду. Напишите только минимальный объем кода, необходимый для прохождения каждой спецификации. Если вам нужно добавить больше кода, сначала добавьте спецификацию (например, проверку допустимого и недопустимого ввода).

После того, как вы описали и создали свои объекты, первая строка вашего сценария Behat пройдет.

Границы модели с интерфейсами

Интерфейсы всегда хороши, потому что это означает, что вы никогда не тестируете чужой код (под которыми я подразумеваю третьих лиц, а не других разработчиков в вашей команде!). Кроме того, вы можете затем создать версию интерфейса в памяти для тестирования. Это разделение задач для уменьшения зависимостей и один из принципов, лежащих в основе ЭБИ Архитектура (Entity-Boundary-Interactor), которая также известна как Шестиугольная архитектура.

Как только вы начнете описывать классы, которые делают что-то с вашими объектами-значениями, вам нужно подумать, следует ли использовать конкретные объекты (например, new Thing()) или лучше использовать двойной? Есть интересное обсуждение с Киараном по этому поводу; но мой вывод состоит в том, что если вы думаете об объектах-значениях как о final тогда их «нельзя» удвоить; кроме того, это облегчает чтение тестов — но кроме того, удвоение в основном используется, когда у вас есть другие зависимости и вы хотите, чтобы тесты были изолированы. Вы должны найти баланс, который работает на вас.

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

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

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

Наконец: Сквозное тестирование.

Поскольку вы уже смоделировали предметную область и знаете, что в ней охвачены все сценарии, тестирование пользовательского интерфейса не должно быть таким всеобъемлющим. Вам не нужно иметь 10 тестов, которые нажимают одну и ту же кнопку, но просто возвращают разные числа, потому что это уже покрыто в среднем слое. Вместо этого вы можете выбрать подходящие сценарии для тестирования и сосредоточиться на взаимодействиях и пользовательском опыте (UX). Кроме того, реальный код пользовательского интерфейса написать проще.

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

В итоге

Моделирование на примере…

Акцентирует внимание на сценарии использования
Помогает разработчикам понять основные сферы деятельности
Поощряет многоуровневая архитектура
Скорости наборы тестов

Вы должны использовать его, когда…

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

Не используйте его, когда…

Проект не основной к делу
Вы строите прототип или краткосрочный проект
Может быть выброшенный когда бизнес меняется
У вас есть нет доступа бизнес-экспертам (но попробуйте изменить это)

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