TDD для пакетной обработки: как это сделать?

Мне нравится "красный / зеленый / рефакторинг" для RoR и т. Д. Просто отлично.

Моя ежедневная работа включает пакетную обработку очень больших файлов от сторонних разработчиков в python и других пользовательских инструментах.

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

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

Q >> Как внедрить принципы TDD в такую ​​среду?

Просто к вашему сведению: модульное тестирование не эквивалентно TDD. TDD - это процесс, в котором модульное тестирование является элементом.

С учетом вышесказанного, если вы хотите внедрить модульное тестирование, вы можете сделать несколько вещей:

Весь новый код / ​​улучшения протестированы

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

Проверьте отдельные фрагменты данных

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

Оттуда проверьте граничные случаи (верхние границы для размера отдельных элементов и количества элементов в пакете). Если вы регулярно запускаете тесты и у вас есть длительные тесты (большие партии?), Большинство организаторов тестов допускают категоризацию, чтобы вы могли запускать эти тесты отдельно (ночью?).

Это должно дать вам прочную базу.

Используя фактические данные

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

Это так же, как и в любой другой среде.

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

Затем напишите тест для каждого правила. Эти тесты не пройдут. Напишите код для исправления теста.

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

Начните с хорошей стратегии программного обеспечения, затем примените TDD.

(Отказ от ответственности: я мог неправильно понять "отток", или TDD, или оба.)

Вот моя предложенная стратегия для пакетной обработки «грязных данных»: Specify-Triage-Execute.

• Составьте спецификацию данных строго и узко, но охватите большинство (скажем, 80% или более) поступающих данных. Назовите эту спецификацию 1 .
• Разработайте модуль Triage (TDD, если хотите), который решает, соответствует ли запись Спецификации 1.
  • Убедитесь, что модуль работает очень быстро.
  • Модуль должен возвращать true / false: он либо соответствует всем правилам, либо нет.
• Разработайте модуль Execute (TDD, если хотите), который анализирует запись, которая, как известно, соответствует Спецификации 1, выполняя любые задачи, необходимые вашим клиентам.
• Примените Triage 1 ко всем входящим данным.
  • Результатом является одно логическое значение для каждой записи. Это в основном разделяет входящие данные на: Спецификация 1 или Неизвестно.
  • Применить Выполнить 1 к данным Спецификации 1, когда это необходимо клиенту.
• Ослабьте правила спецификации 1, чтобы допустить 80% оставшихся данных. Назовите эту спецификацию 2 .
• Разработайте Triage 2 и выполните 2 . Примените его к любым данным, которые не соответствуют Спецификации 1.
• Повторяйте столько уровней, сколько необходимо, пока оставшиеся данные не станут достаточно маленькими, чтобы их можно было обрабатывать вручную каждый день.

Эффективность Tidbit:

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

Тидбит «Вы должны знать, что хотите построить, прежде чем делать TDD»:

Specify-Triage-Execute - это один из способов обеспечения управляемости требований на каждом уровне и обеспечения будущего роста.

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