Почему платформы xUnit не позволяют тестам работать параллельно?

Знаете ли вы о какой-либо инфраструктуре xUnit, которая позволяет параллельно выполнять тесты, чтобы использовать несколько ядер на современном компьютере?

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

Есть ли что-то более глубокое, что препятствует распределению (хотя бы некоторых) тестов по нескольким потокам?

NUnit 2.5 в комплекте pNUnit, который позволяет выполнять тесты параллельно.

Этот выпуск включает в себя pNUnit, расширенный NUnit Runner для распределенных параллельных тестов. Программа pNUnit была разработана в Codice Software для использования при тестировании Plastic SCM и внесена в NUnit. Для получения дополнительной информации об использовании pNUnit посетите сайт pNUnit.

Сторона JUnit имеет параллельный юнит, а также амино .

Чтобы ответить на вторую часть вашего вопроса: есть ли что-то более глубокое, что препятствует распределению (хотя бы некоторых) тестов по нескольким потокам?

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

Представьте себе простой класс «log to file». Когда вы создаете экземпляр, он открывает файл для записи, а когда вы освобождаете экземпляр, он закрывает файл. Итак, первый тест создает экземпляр и запускает тест. Второй тест делает то же самое во втором потоке. И терпит неудачу, потому что второй экземпляр не может получить доступ для записи в файл. Но если запустить по одному, все тесты пройдут.

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

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

Хотя JUnit сам по себе может этого не допустить (хотя я не очень хорошо знаком с его последними версиями), Maven с его плагином Surefire имеет возможность запускать тесты параллельно. Я еще не пробовал это все же.

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

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

Методы многопоточности на многопроцессорных системах становятся все лучше с появлением многопроцессорных ПК. Однако пройдет много времени, прежде чем они станут широко использоваться.

Некоторые наборы тестов имеют зависимости между тестами, которые не нужно явно указывать при выполнении тестов в одном потоке. Однако на многопаровом двигателе они должны быть указаны явно. (Где должны существовать такие зависимости - это другой вопрос.)

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

MBUnit может выполнять тесты параллельно, просто указав некоторые атрибуты уровня сборки.

[assembly: DegreeOfParallelism(6)]
[assembly: Parallelizable(TestScope.All)]

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

xUnit 2.0 также должен поддерживать параллельное модульное тестирование, но я еще не пробовал.