TDD или test-driven design/developmentПодход «сначала тесты», когда тестирование идёт не в конце, а до написания программы, был впервые предложен в концепции экстремального программирования в конце девяностых. Суть его в том, что мы сначала пишем приёмочный тест — например, что сложение двух конкретных чисел 2 и 3 даёт на выходе 5, и только после этого — код, реализующий этот алгоритм.
На следующей итерации добавляем новый тест, например, для −2 и 3, чтобы наш метод умел работать с отрицательными числами, и модифицируем код так, чтобы он удовлетворял обоим тестам. И так далее. Добавление каких-то тестов сделает код нерабочим и это штатная ситуация — значит, пришло время модифицировать программу.
Такой же метод прекрасно ложится в область проектирования. Мы формулируем набор приёмочных критериев до того, как начинаем конструировать решение, а когда начинаем конструирование, то переделываем конструкцию до тех пор, пока она не удовлетворит всем критериям.
Разберём на примере. Допустим, мы проектируем механизм, который позволит сотрудникам отдела обрабатывать стопку задач. Мы знаем, что человечество уже изобрело очередь — и даже её электронную версию — но пока мы не знаем в деталях, как она должна быть организована в нашем случае. Именно это «не знаем в деталях» и должно быть спроектировано.
Теперь запишем критерии готовности для будущего дизайна. Обратите внимание на их формулировки: на каждый вопрос можно быстро дать бинарный ответ — удовлетворили мы текущим решением конкретному критерию или нет.
Список критериев готовности механизма распределения задач по сотрудникам:
— Весь объём работ распределен между сотрудниками на смене. Задачи не назначаются тем, кто сейчас не работает с системой.
— Обеспечена одновременная работа с очередью старых и новых входящих заявок. — Работа с очередью не блокирует другую работу с таблицей документов.
— Виден объём отдельных очередей по типам задач и общей очереди.
— Определён непротиворечивый принцип приоритизации задач.
— Более приоритетные задачи берутся раньше менее приоритетных.
— Задача изымается из очереди, если по ней проведены ключевые изменения.
— Отложенные задачи возвращаются прежнему исполнителю через некоторое время.
— У сотрудника есть возможность вернуться к отложенным им задачам.
— Есть отказ от задачи из-за отсутствия компетенций.
— Есть способ перейти ко всем задачам одного контрагента.
— Очередь прощает ошибки при ложном сообщении сотрудника о готовности по заявке.
Теперь можно начать циклично «выращивать» конструкцию интерфейса.
По материалам статьи Андрея Шапиро «Проектирование через тестирование и запутанные верёвки».@productsense