Стенды и макеты

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

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

Это испытательные стенды и макеты.

Стенды и макеты создаются как вспомогательные программы, параллельные к основной программе и служат для временных утилитарных целей. В каталогах stands и makets по некоторым проектам у меня могут оказаться десятки мелких программок.

Когда какие именно я делаю и зачем?

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

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

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

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

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

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

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

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

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

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

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