TDD для пакетної обробки: як це зробити?

Мені подобається «червоний / зелений / рефактор» для RoR тощо.

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

Збільшити атрибути цих файлів є високим, тому досить багато виправлень / удосконалень застосовуються досить часто.

Регресійне тестування через відомий масив даних тестів з очікуваними результатами не існує. Найближче працює проти останньої партії з новими тестовими кодами, переконайтеся, що вона не підірвана, а потім застосуйте перевірку на місцях та статистичні тести, щоб перевірити, чи дані все ще виглядають у порядку.

Q >> Як ввести принципи TDD у таке середовище?

Просто FYI: Тестування блоку не еквівалентно TDD. TDD - це процес, тестування якого є одиницею.

З огляду на це, якщо ви хочете здійснити тестування одиниць, то ви можете зробити кілька речей:

Всі нові коди / удосконалення протестовані

Таким чином, вам не доведеться проходити і перевіряти все те, що вже існує, тому початковий перелік тестування одиниць значно менший.

Тестуйте окремі фрагменти даних

Тестування чогось, що може містити велику кількість даних, може призвести до безлічі випадків і розривів у тестовому покритті. Натомість розглянемо варіант 0, 1, багато. Тестуйте "партію" з 0 елементами, 1 елементом та багатьма елементами. У випадку з 1 елементом перевірити різні перестановки, в яких можуть бути дані цього елемента.

Звідти перевірити крайові корпуси (верхні межі розміру окремих елементів та кількості елементів у партії). Якщо ви запускаєте тести регулярно і у вас є тривалі тести (великі партії?), Більшість бігунів тестів дозволяють категоризувати, щоб ви могли запускати ці тестові справи окремо (щоночі?).

Це має дати вам міцну базу.

Використання фактичних даних

Подання "фактичних" раніше використовуваних даних, як ви робите зараз, не є поганою ідеєю. Просто доповніть їх добре сформованими даними тесту, щоб ви одразу дізналися конкретні моменти відмови. Якщо не вдається обробити фактичні дані, ви можете перевірити результати пакетного процесу, виготовити блок-тест для повторення помилки, а потім повернетесь у червоний / зелений / рефактор з корисними випадками регресії.

Це те саме, що і будь-яке інше середовище.

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

Потім напишіть тест для кожного правила. Ці тести не вдасться. Напишіть код, щоб виправити тест.

Регресійне тестування з відомими тестовими даними, про які ви говорите, не є одиничним тестуванням. Це було б тестування інтеграції, це відрізняється від TDD. З TDD у вас може бути один тест для перевірки того, що ви можете завантажити файл, але, як правило, жоден інший тест насправді не наближається до файлу даних із тестовими даними. Натомість ви б імітували дані, необхідні для виконання певного правила, використовуючи глузуючий об’єкт.

Почніть з гарної програмної стратегії, а потім застосуйте TDD.

(Відмова від відповідальності: я, можливо, неправильно зрозумів "churn", або TDD, або те і інше.)

Ось моя запропонована стратегія пакетної обробки "брудних даних": Specify-Triage-Execute.

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

Ефективність роботи:

Збережіть усі результати Triage (історичні чи поточні), пов’язані із записом. Якщо жодні модулі Triage не змінені з останнього запуску, то його не потрібно повторно виконувати на старих даних.

"Ви повинні знати, що ви хочете створити, перш ніж робити TDD":

Specify-Triage-Execute - це один із способів підтримувати вимоги, які можна керувати на кожному рівні, і дозволяє в майбутньому зростати.

(Якщо хтось знає стандартні правильні умови для цих трьох кроків, будь ласка, повідомте мене, я відредагую свої відповіді.)