Як ви протестуєте програмне забезпечення, яке відрізняється часом?

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

Нещодавній приклад, з яким я зіткнувся, - це налаштування роботи на крон, яку потрібно виконувати з другого на останній день кожного місяця. Для цього потрібен сценарій оболонки з вкладкою cron, щоб отримати правильний день місяця для cron, як-от:

1 0 [shell command] * * [my script]

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

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

Окрім тестування одиниць, є ще дві стратегії налаштування автоматизованих тестів для вирішення конкретних проблем ОС:

• Віртуалізація : Ви налаштовуєте декілька образів ОС (наприклад, використовуючи VMWare ) з потрібними точними конфігураціями, налаштовуєте спосіб автоматичного витягування двійкового файлу для тестування (зазвичай, встановивши спеціальний каталог у простір VM), а потім виконайте тест.

Або:

• Інструментарій : вручну додайте ifдо програми особливі умови, які змусять програму поводитись інакше. У Unix це можна зробити, перевіривши, чи встановлена ​​певна змінна середовище, наприклад FOOBAR_TEST_TIME_WITH_T=500. Тоді ваші автоматизовані тести просто використовуватимуть різні параметри змінних оточення та різні змінні середовища для виконання того, що вам потрібно.

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

Є також автоматичні інструментальні інструменти, які можуть переписати ваші бінарні файли, щоб отримати інші бажані ефекти, як-от файлова система заповнена.

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

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

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

Оскільки ви згадали про кронтаб, я припускаю, що ви працюєте в nix середовищі. У такому випадку, я думаю, варто було б ознайомитися з libfaketime:
http://www.code-wizards.com/projects/libfaketime/

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

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

Кращим способом впоратися з цим є "глузування з годинника", використовуючи один фокус програмування або інший, щоб підробити час. У скриптах оболонки ви можете використовувати синтаксис $ {: -}, щоб використовувати дату, встановлену в змінній середовища, і повернутися на фактичний час, якщо це не було вимушено.

В інших мовах ми використовуємо макетні бібліотеки або будуємо абстракцію цілодобово.

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