Может ли тестовый скрипт Perl определить, запускается ли он из жгута параллельно?

Question

Проблема:

Управление внешним состоянием в тестовом файле уменьшает возможный параллелизм вашего набора тестов.

То, что я тестирую, точно манипулирует внешним состоянием (а затем сбрасывает его).

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

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

Обратите внимание, что простого анализа переменной окружения HARNESS_OPTIONS из вашего сценария недостаточно для обнаружения условия: например, prove -j3 не установит его.

Обновление

Хотя существует множество способов сообщить вашему тестовому скрипту, что он запускается в параллельном жгуте (см. Ответ Брайана ниже), не существует единственного стандартного способа сделать это, о котором я думал может быть (но не правильно сформулировал это в моем вопросе).

Я думал о чем-то вроде, хм, ну, я читал это в вашей (отлично!) Эффективном программировании на Perl Книга, Брайан, что-то вроде тесты сопровождающего , не уверен в термин сейчас, который вы обычно запускаете, только если вы являетесь сопровождающим модуля, а не во время установки на компьютер пользователя. Похоже, вы помните, что для этого было принято соглашение об использовании некоторой переменной environement.

Answer 1

Команда prove создает сам объект тестового жгута, поэтому передает аргументы непосредственно конструктору класса тестового жгута (обычно TAP :: Harness ). Вы не видите эти аргументы.

Вы можете пойти сюда несколькими способами:

• Напишите оболочку для prove, чтобы также установить переменную среды, если вы используете -j3.
• Создайте свой собственный подкласс Test::Harness, чтобы сделать то же самое, если он получает аргумент jobs, и укажите подкласс в вашей конфигурации для prove.
• Не используйте prove (мой любимый).
• Используйте семафор из ваших тестовых программ, чтобы заметить, что другая тестовая программа имеет контроль
• Перемещение внешних взаимодействующих частей в общую библиотеку, которая может сообщить своим вызывающим, если кто-то уже имеет контроль
• Многие другие вещи

Answer 2

У меня была несколько похожая потребность в обнаружении выполнения в prove.Я хотел подавить вывод из Test::More::diag(), если я запускал весь набор тестов, используя prove.Но когда я выполняю тест по отдельности вручную, я делаю хочу увидеть эти диагностические сообщения.Я делаю это, проверяя, подключен ли STDERR к терминалу.

diag("prove will not see this message") if (-t STDERR);

Я думаю, что это имеет смысл не только для использования в среде prove, идея в том, что если STDERR отображается вчеловек, тогда примите интерактивное использование и будьте более болтливыми.

Answer 3

я думаю, что возможно сделать это с помощью функции caller - (caller (4)) [0] будет предполагать, что я верну аргументы того, из чего он был вызван - который может быть j3 - это будет стоить сравнить с другие значения вызывающего абонента, хотя.

Я думаю, что стоит упомянуть об этом в этом потоке, так как этот поток также часто является первым хитом для обнаружения, когда скрипт вызывается из жгута или теста, что (вызывающий) [1] является лучшим способом, который я когда-либо видел, чтобы знать если что-то было запущено как часть теста

Answer 4

Я работаю над альтернативным решением этой проблемы по этому вопросу: Как запустить некоторые, но не все тесты в наборе тестов Perl параллельно? .

Мой путь заключается в исправлении prove для добавления параметра, подобного --serial-tests FILE, который будет ссылаться на тесты списка файлов, которые всегда должны выполняться последовательно. Вы можете «установить и забыть об этом», а затем использовать опцию «-j», как хотите. Если вы укажете один из этих тестов, остальные тесты будут выполняться параллельно, но эти тесты будут выполняться последовательно.

Мне кажется, что предпочтительнее избегать выполнения тестов или разбивать их на собственные тестовые прогоны.

Сегодня вечером у меня есть рабочее доказательство концепции, которым я поделюсь с сопровождающими. Я буду публиковать дальнейшие заметки о прогрессе через другую страницу Q / A.