Как сделать надежное интеграционное тестирование обработки сигналов Unix в PHP?

Я пишу серверную систему, которая работает в фоновом режиме. В очень упрощенном виде у него есть свой собственный язык сценариев, что означает, что процесс может быть написан на этом языке для запуска сам по себе, или он может вызывать другой процесс и т. Д. Я конвертирую эту систему из тривиального задания cron PHP в который только один экземпляр разрешен одновременно для набора длительных процессов, управляемых Supervisor.

Имея это в виду, я осознаю, что эти процессы могут быть убиты в любое время, либо мной самим в процессе разработки, либо, возможно, Supervisord в ходе обычной остановки или перезапуска работника. Я хотел бы добавить некоторую правильную обработку сигналов для обеспечения того, чтобы работники убирались за собой, и, при необходимости, регистрировать, где задача была оставлена ​​в прерванном состоянии.

Я разработал, как включить обработку сигналов с помощью тиков и pcntl_signal()и моя обработка в настоящее время, кажется, работает нормально. Тем не менее, я хотел бы проверить это, чтобы убедиться, что это надежно. Я написал несколько ранних интеграционных тестов, но они не кажутся такими уж солидными, в основном потому, что во время разработки возникали всевозможные странные проблемы, связанные с состоянием гонки, которые было сложно определить.

Я хотел бы получить совет или руководство по отправке сигналов уничтожения в тестах PHPUnit, чтобы повысить уверенность в том, что моя обработка sig надежна. Моя нынешняя стратегия:

• Использует PHPUnit
• Когда базовая система работает, она создает файлы журналов различного типа, которые можно использовать для отслеживания момента завершения задачи.
• Базовая система запускается с использованием отдельного сценария PHP в фоновом режиме, используя system() команда в тесте PHPUnit. Моя команда похожа на php script.php > $logFile 2>&1 & то есть перенаправить весь вывод в файл журнала, а затем перенести его в фоновый режим, чтобы тестовый метод мог его отслеживать
• Фоновый скрипт записывает свой PID в файл, который будет убивать PID
• Это достоверно фиксируется тестом, многократно сканируя его и usleepмежду сканированиями
• Затем тест ожидает определенного состояния путем сканирования базы данных, usleepмежду сканированием и выдачей kill <pid> когда он будет готов
• Затем он ожидает, что обработчик сигнала включится и запишет новое состояние базы данных, usleepснова, чтобы не забивать базу данных
• Наконец, он будет либо определять, находится ли база данных в правильном состоянии, либо нет, после максимального времени задержки, которое проходит / не проходит тест.

Конечно, со всеми этими ожиданиями / проверками, это кажется немного странным и вполне готовым к гоночным условиям всех видов. В настоящее время у меня такое ощущение, что тесты будут проваливаться примерно в 2% случаев, но я не смог провалить тест в течение дня или около того. Я планирую провести иммерсионное тестирование, и если я получу какие-либо ошибки, я опубликую это здесь.

Интересно, могу ли я упростить это, попросив тестируемую систему kill само по себе, что удалит два уровня проверки ожидания (один для ожидания PID, а другой — для ожидания перехода базы данных в правильное состояние перед командой kill)^†. Это по-прежнему оставляло бы цикл ожидания-проверки после того, как было выполнено kill, но я все же могу обнаружить, что наличие такой проверки на практике не является проблемой.

Тем не менее, я осознаю, что весь мой подход может быть сорван, и есть лучший подход для такого рода вещей. Есть идеи? В настоящее время я думаю просто увеличить время ожидания на случай, если PHPUnit вводит какие-то странные задержки. Я также посмотрю, смогу ли я получить случай неудачи для проверки журналов.

† К сожалению, это не сильно упростит ситуацию. Я только что попробовал это на простом тесте интеграции сигнала, который я считаю надежным, и так как system() немедленно возвращается, он все еще должен ждать цикла, чтобы определить правильную запись журнала, а затем для правильного результата после уничтожения. Однако больше не нужно ждать, пока PID будет записан во временный файл, так что исключен хотя бы один цикл.