Чому рамки xUnit не дозволяють тестам паралельно працювати?

Чи знаєте ви про будь-який фреймворк xUnit, який дозволяє паралельно запускати тести, використовувати декілька ядер у сучасній машині?

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

Чи є щось глибше, що перешкоджає поширенню (принаймні деяких) тестів на декілька потоків?

NUnit 2.5 в комплекті pNUnit, що дозволяє виконувати тести паралельно.

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

Сторона JUnit має паралельно-джуніт , а також аміно .

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

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

Уявіть простий клас "журнал у файл". Коли ви створюєте екземпляр, він відкриває файл для запису, коли ви звільняєте екземпляр, він закриває файл. Отже, перший тест створює екземпляр і починає виконувати тест. Другий тест робить те ж саме у другій нитці. І не вдається, оскільки друга інстанція не може отримати доступ до запису до файлу. Але якщо запустити один за одним, всі тести пройшли б.

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

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

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

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

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

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

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

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

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

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

Я використовую цей проект, щоб паралельно досить успішно проводити тести на селен паралельно. На жаль, проект вже не дуже живий.

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