Вот типичный вопрос «Мне не нравится TDD»: тема «
Действительно ли TDD работает для сложных проектов? »
Часть вопроса была сосредоточена на сложности подготовки контрольных примеров, которые соответствуют требованиям. В частности, были некоторые проблемы с противоречивыми и противоречивыми требованиями.
Вот что сработало для меня.
Подготовка . Пользователи предоставляют тестовые примеры в виде электронной таблицы, показывающей бизнес-правила. Столбцы являются атрибутами какого-либо бизнес-документа или дела. Строки являются конкретными тестовыми примерами. Пользователи могут (и часто будут) делать это без промедления. Часто сложные аналитические требования, написанные бизнес-аналитиками, основаны на такой таблице.
Это удивительно легко для пользователей. Это просто электронная таблица (или несколько электронных таблиц) с конкретными примерами. Пользователям часто легче привести конкретные примеры, чем написать более общие бизнес-правила.
Автоматизированный тестовый набор
Вот что может легко произойти дальше.
Напишите скрипт Python для разбора электронной таблицы и извлечения кейсов. Будут некоторые специальные правила, непоследовательные тесты, небольшие технические проблемы. Таблицы будут отформатированы плохо или непоследовательно.
После анализа случаев легко создать какой-
либо шаблон Unittest.TestCase . Используйте
Jinja2 или даже класс Python
string.Template, чтобы набросать шаблон для тестового примера. Специфика заполняется в шаблон модульного теста.
Схема построения тестового примера примерно такая. Детали варьируются в зависимости от целевого языка, дизайна тестового набора и общего подхода к упаковке тестового набора.
t = SomeTemplate()
for case_dict in testCaseParser( "some.xls" ):
code= t.render( **case_dict )
with open(testcaseName(**case_dict ),'w') as result:
result.write( code )
Теперь у вас есть полностью заполненное дерево классов, модулей и пакетов модульного тестирования, созданных из исходных документов конечного пользователя.
У вас есть свои тесты. Вы можете начать делать TDD.
Сценарии
Одна из самых ранних проблем, с которой вы столкнетесь, — это разбитые таблицы тестовых примеров. Неправильные заголовки столбцов, неправильное форматирование, что-то не так. Познакомьтесь с пользователем или экспертом, который создал электронную таблицу, и исправьте ситуацию.
Возможно, здесь есть какая-то деловая тонкость. Или, может быть, они просто небрежны. Важно то, что электронные таблицы должны анализироваться простыми сценариями для создания простых модульных тестов. Если вы не можете найти работоспособное решение, у вас есть большие проблемы, и лучше решить их сейчас, чем пытаться перейти к реализации с пользователем или МСП, которые не хотят сотрудничать.
Другая проблема, с которой вы столкнетесь, заключается в том, что тесты будут противоречивыми. Сначала это будет сбивать с толку, потому что у вас есть код, который прошел один тест и не прошел другой тест, и вы не можете сказать, в чем различия между тестами. Вы должны встретиться с пользователями или МСП и решить проблему. Почему тесты противоречивы? Часто в электронной таблице отсутствуют атрибуты — атрибуты, которые каждый из них предполагал, — и атрибуты, которые вы нигде явно не записывали. В других случаях возникает путаница, которую необходимо устранить, прежде чем начинать программирование.
Большой выигрыш
Когда все тесты пройдены, вы готовы к тестированию производительности и окончательной приемке. Вот где TDD (и наличие у пользователей тестовых случаев) хорошо окупается.
Допустим, мы выполняем финальные приемочные тесты, и пользователи отказываются от какого-то результата. «Не может быть прав», — говорят они.
Что мы делаем?
На самом деле, почти ничего. Получить правильный ответ в электронную таблицу где-нибудь. Тестовые случаи были неполными. Это всегда случается. Вне TDD это называется «проблемой требований» или «ползучестью» или чем-то еще. Внутри TDD это называется «тестовое покрытие», и требуется еще несколько тестовых случаев. В любом случае, тестовые случаи всегда неполны.
Может случиться так, что они на самом деле меняют более ранний тестовый пример. Пользователи тоже ошибаются в примерах. В любом случае (упущение или ошибка) мы просто исправляем электронные таблицы, восстанавливаем контрольные примеры и запускаем процесс TDD с пересмотренным набором контрольных примеров.
Исправление ошибок
Интересно отметить, что исправление ошибки после запуска производства ничем не отличается от проблемы с приемочным тестом. На самом деле это ничем не отличается от всего, что произошло до сих пор.
Пользователь замечает ошибку. Они сообщают об этом. Мы просим конкретный пример, который иллюстрирует правильный ответ.
Мы восстанавливаем контрольные примеры из электронных таблиц и начинаем разработку. 80% времени новый пример фактически является изменением существующего примера. И поскольку пользователи создали таблицы с примерами с тестовыми данными, они могут поддерживать эти таблицы, чтобы уточнить ошибки. 20% времени это новое требование. В любом случае, тестовые случаи настолько полны и последовательны, насколько способны пользователи.