Лучшие практики для TDD и создания отчетов
Я пытаюсь стать более знакомым с тестом управляемые подходы. Один недостаток для меня состоит в том, что большая часть моего кода является сгенерированным контекстом для создания отчетов (Документы в формате PDF, изображения диаграммы). Всегда существует сложный вовлеченный разработчик и нет никакого легкого теста правильности. Никакой шанс протестировать просто фрагменты!
Вы знаете методы TDD для этой ситуации?
7 ответов
Вы можете использовать разработку приемочного теста для замены модулей и проверили отчеты для хорошо известных данных, используемых в качестве ссылок.
Однако этот вид теста не дает мелкозернистой диагностики, поскольку единичные тесты делают, они обычно предоставляют только результат Pass / Fail, и должны часто изменяться отчеты, ссылки должны быть регенерированы и повторно подтверждены как Что ж.
Некоторые приложения или рамки - это просто наножно, а не бдружерное, и на самом деле нет много, что вы можете сделать с этим.
Я предпочитаю вообще избегать таких структур, но если это абсолютно вынуждено иметь дело с такими проблемами, может быть полезно извлечь всю логику в тестируемую библиотеку, оставляя только декларативный код в рамках в рамках.
Вопрос, который я задаю себе в этих ситуациях, - это « Как я знаю, я понял правильно »?
Я написал много кода в моей карьере И почти все это не сработало в первый раз. Почти каждый раз, когда я вернулся и изменил код для рефакторинга, изменения функций, производительности или исправления ошибки, я снова сломал его. TDD защищает меня от себя (Слава благодарность!).
В случае сгенерированного кода я не чувствую себя вынужденным проверить код. То есть я доверяю генератору кода. Однако я хочу проверить мою входы к генераторам кода. Как раз, то, как это сделать, зависит от ситуации, но общий подход - спросить себя, как я могу понять это неправильно, а затем выяснить, как убедиться, что я понял правильно.
Может быть, я пишу автоматический тест. Может быть, я осмотру что-то вручную, но это довольно рискованно. Может быть, что-то еще. Это зависит от ситуации.
, чтобы положить немного иное вращение на ответы от Марка, казанны и Джей Базузи:
Ваша проблема заключается в том, что интерфейс отчетов создает формат данных, вывод которого вы не можете легко осмотреть в разделе «Проверьте» часть ваших тестов.
Путь для решения этой проблемы состоит в том, чтобы:
есть некоторые очень высокоуровневые тесты интеграции, которые поверхностно проверили, что ваш задний код правильно подключен к вашему интерфейсу. Я обычно называю эти тесты «дымовые тесты», как в «если я включу силу, и курят, это плохо».
Найдите другой способ проверить ваш код отчетов. Либо проверьте промежуточную структуру данных выходных данных, либо реализуйте альтернативный выходной интерфейс, который является более удобным, HTML, открытым текстом, что угодно.
Это похоже на общую проблему тестирования веб-приложений: невозможно автоматически проверить, что «страница выглядит правильно». Но достаточно проверить, что слова и цифры в данных страницы являются правильными (используя программное сушу браузера в качестве механизма и скребка страницы) и иметь несколько поверхностных функциональных испытаний (с селеном или ветряной мельницей), если страница критически зависима на JavaScript.
Вы можете попробовать использовать веб-службу для вашей отчетности источника данных и тестировать это, но у вас нет модульных тестов для рендеринга. Это то же самое, что у вас есть при тестировании представления. Конечно, вы можете использовать рамки веб-тестирования, как Selenium, но вы, вероятно, не будете практиковать TDD. Вы будете создавать тесты после выполнения вашего кода.
Короче говоря, используйте здравый смысл. Вероятно, не имеет смысла пытаться проверить рендеринг отчета. Вы можете иметь ручные тестовые случаи, которые тестер придется пройти через руку или просто проверить отчеты самостоятельно.
Возможно, вы также захотите проверить «. Сколько подразделения для тестирования вам нужна? - Ответ на проверку »
Рассмотрим возможность извлечения текста из PDF и его проверки. Однако это не даст вам возможности отформатировать текст. Некоторые программы извлечения в формате pdf могут извлекать изображения, если графики находятся в pdf.
Столкнулся с этой ситуацией, я пробую два подхода.
Золотой главный подход. Создайте отчет один раз, проверьте его сам, а затем сохраните его как «золотой мастер». Напишите автоматизированный тест, чтобы сравнить свой вывод с золотым мастером, и потерпеть неудачу, когда они отличаются.
Автоматизируйте тесты для данных, но проверьте формат вручную. Я автоматизирую проверку модуля, который генерирует данные отчета, но для проверки формата отчета я генерирую отчет с жесткокодированными значениями и проверяю отчет вручную.
Я настоятельно рекомендую вам не для генерирования полного отчета, чтобы проверить правильность данных в отчете. Когда вы хотите проверить отчет (не данные), затем генерируйте отчет; Когда вы хотите проверить данные (не в формате), то только генерируют данные.