Есть ли возможность настроить UnitTestRunner так чтобы тесты выполнялись не один за одним а два-четыре (по к-во процов) паралельно?

Здравствуйте, Igor Sukhov, Вы писали:

IS>Есть ли возможность настроить UnitTestRunner так чтобы тесты выполнялись не один за одним а два-четыре (по к-во процов) паралельно?

Неужели никого не интересует возможность ускорить в 2-4 раза выполнения однопоточных тестов (таких тестов думаю подавляющее большинство) на дуал-квадро-коре машинках.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Неужели никого не интересует возможность ускорить в 2-4 раза выполнения однопоточных тестов (таких тестов думаю подавляющее большинство) на дуал-квадро-коре машинках.

Очень-очень волнует.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Неужели никого не интересует возможность ускорить в 2-4 раза выполнения однопоточных тестов (таких тестов думаю подавляющее большинство) на дуал-квадро-коре машинках.

Пиши тесты соответственно.
Unit Test Runner не имеет права распараллеливать тесты по своему усмотрению

Здравствуйте, xvost, Вы писали:

X>Unit Test Runner не имеет права распараллеливать тесты по своему усмотрению

А если помечать их специальным атрибутом, например [AllowParallelExecution] и сделать, чтобы UTR распознавал его?

Здравствуйте, nikov, Вы писали:

N>А если помечать их специальным атрибутом, например [AllowParallelExecution] и сделать, чтобы UTR распознавал его?

В данный момент мы поддерживаем NUnit, а не свою доморощенную систему где делай что хочешь.

Вот когда старикан Charlie Poole доделает свою мегасистему, то там будет все....

Здравствуйте, xvost, Вы писали:

IS>>Неужели никого не интересует возможность ускорить в 2-4 раза выполнения однопоточных тестов (таких тестов думаю подавляющее большинство) на дуал-квадро-коре машинках.

X>Пиши тесты соответственно.
X>Unit Test Runner не имеет права распараллеливать тесты по своему усмотрению

Ну так я об это и пишу — почему не дать ему это право, сэкономив разработчикам кучу времени. Медленные выполнение тестов (зная что оно может выполняться в 2-4 раза быстрее) — это как медленная компиляция — очень frustrating.

Я просто не вижу тут технической проблемы. Я не говорю что ее нет — я просто ее не вижу.

Здравствуйте, nikov, Вы писали:

X>>Unit Test Runner не имеет права распараллеливать тесты по своему усмотрению
N>А если помечать их специальным атрибутом, например [AllowParallelExecution] и сделать, чтобы UTR распознавал его?
Зачем все это нужно — не пойму? Запускаешь тест в своем потоке (макс. число потоков == числу процессоров), отрабатывает тест — поток выполняет след. тест и так пока не кончатся.

Здравствуйте, Igor Sukhov, Вы писали:

X>>>Unit Test Runner не имеет права распараллеливать тесты по своему усмотрению
N>>А если помечать их специальным атрибутом, например [AllowParallelExecution] и сделать, чтобы UTR распознавал его?
IS>Зачем все это нужно — не пойму? Запускаешь тест в своем потоке (макс. число потоков == числу процессоров), отрабатывает тест — поток выполняет след. тест и так пока не кончатся.

Не все тесты заведомо потокобезопасны.

Здравствуйте, Igor Sukhov, Вы писали:

IS>Я просто не вижу тут технической проблемы. Я не говорю что ее нет — я просто ее не вижу.

Тут есть концептуальное противоречие . TestFixture может иметь сосотояние, которое обычно строится в OnFixtureSetup и используется в каждом тесте последовательно.

Здравствуйте, achmed, Вы писали:

A>Здравствуйте, Igor Sukhov, Вы писали:

IS>>Я просто не вижу тут технической проблемы. Я не говорю что ее нет — я просто ее не вижу.

A>Тут есть концептуальное противоречие . TestFixture может иметь сосотояние, которое обычно строится в OnFixtureSetup и используется в каждом тесте последовательно.

Ну такое концептуальное противоречие решается в 10 строчек (в основном вызовы GetCustomAttributes):

*проверяем наличие OnFixtureSetup аттрибута
*если он есть — не распаралелливаем тесты в TestFixture
*если его нет — выполняем тесты паралельно, наслаждаемся скоростью.

Так будет работать или еще есть концептуальные противоречия?

Здравствуйте, Igor Sukhov, Вы писали:

IS>Ну такое концептуальное противоречие решается в 10 строчек (в основном вызовы GetCustomAttributes):

IS>*проверяем наличие OnFixtureSetup аттрибута
IS>*если он есть — не распаралелливаем тесты в TestFixture
IS>*если его нет — выполняем тесты паралельно, наслаждаемся скоростью.

IS>Так будет работать или еще есть концептуальные противоречия?

Могут быть и другие источники ошибок, например тесты могут юзать однопользовательскую БД и др. внешние ресурсы.

Интересно, стандартный nunutrinner запускает каждый testfixture в отдельном домене? если нет то будут еще и проблемы со статическими переменными.

Здравствуйте, achmed, Вы писали:

IS>>Ну такое концептуальное противоречие решается в 10 строчек (в основном вызовы GetCustomAttributes):

IS>>*проверяем наличие OnFixtureSetup аттрибута
IS>>*если он есть — не распаралелливаем тесты в TestFixture
IS>>*если его нет — выполняем тесты паралельно, наслаждаемся скоростью.

IS>>Так будет работать или еще есть концептуальные противоречия?

A>Могут быть и другие источники ошибок, например тесты могут юзать однопользовательскую БД и др. внешние ресурсы.
я думаю большинство из нас все таки тесты юнит тесты для однопользовательский БД не пишут (у меня около 350 тестов и ни одного для работы с однопользователской БД) — для внешних ресурсов лучше применять сессионные сценарии — т.е. при запуске теста создается уникальный id сессий и все ресурсы выделяеются через него — т.е. колизий быть не должно.

В конце концов пускай те кто пишут сильно-зависимые (по моему это плохой стиль которые не следует поощрять) тесты — просто выключат эту потенциальную feature и завидуя смотрят как все летает у тех кто пишет мало-связанные тесты.

A>Интересно, стандартный nunutrinner запускает каждый testfixture в отдельном домене? если нет то будут еще и проблемы со статическими переменными.

Зачем равняться на убогий буржуйский юниттестраннер — его место у .... в .... на билдсервере — где временные рамки не такие жесткие. Надо просто усовершеностовать Resharper-кий Test Runner.

Здравствуйте, Igor Sukhov, Вы писали:

IS>>>Так будет работать или еще есть концептуальные противоречия?
Принципиальных противоречий нет, ведь уже сейчас можно запустить несколько сессий одновременно. В какой-нибудь будущей версии (вряд ли в четвертой) мы собираемся сделать:
* запуск тестов из одной сессии в заданном количестве потоков
* случайный порядок запуска тестов
* заданное количество раз повторить запуск тестов

Проблемы здесь исключительно с наличием времени аккуратно всё это реализовать и ничего при этом не сломать

Здравствуйте, orangy, Вы писали:

IS>>>>Так будет работать или еще есть концептуальные противоречия?
O>Принципиальных противоречий нет, ведь уже сейчас можно запустить несколько сессий одновременно. В какой-нибудь будущей версии (вряд ли в четвертой) мы собираемся сделать:
!!

O>* запуск тестов из одной сессии в заданном количестве потоков
Этож просто праздник какой-то. Осталось только дату праздника узнать =)

O>* случайный порядок запуска тестов
O>* заданное количество раз повторить запуск тестов

O>Проблемы здесь исключительно с наличием времени аккуратно всё это реализовать и ничего при этом не сломать
Чтобы ничего не сломать — надо чаще тестировать — а чтобы чаще тестировать нужно чтобы тесты быстро выполнялись =))) (негромко: на многопроцессорных машинках в том числе)

Спасибо.

Здравствуйте, Igor Sukhov, Вы писали:

O>>Проблемы здесь исключительно с наличием времени аккуратно всё это реализовать и ничего при этом не сломать
IS>Чтобы ничего не сломать — надо чаще тестировать — а чтобы чаще тестировать нужно чтобы тесты быстро выполнялись =))) (негромко: на многопроцессорных машинках в том числе)
Чтобы ничего не сломать, надо больше тестов писать, ибо у нас TeamCity на нескольких десятках агентов всё это гоняет и скорость выполнения тестов — не самая главная, хотя и важная деталь. К сожалению, написать тесты на то, что чьи-то тесты в параллельном исполнении выполняются корректно, с точностью до корректности самих тестов не представляется возможным

Здравствуйте, orangy, Вы писали:

IS>>Чтобы ничего не сломать — надо чаще тестировать — а чтобы чаще тестировать нужно чтобы тесты быстро выполнялись =))) (негромко: на многопроцессорных машинках в том числе)
O>Чтобы ничего не сломать, надо больше тестов писать, ибо у нас TeamCity на нескольких десятках агентов всё это гоняет и скорость выполнения тестов — не самая главная, хотя и важная деталь. К сожалению, написать тесты на то, что чьи-то тесты в параллельном исполнении выполняются корректно, с точностью до корректности самих тестов не представляется возможным

эту концептуальную невозможность оставим на будущее =)

Здравствуйте, orangy, Вы писали:

я снова сел писать и выполнять тесты,
и поэтому снова:

товарищи, господа, непримкнувшие к первым двум группам по идейным соображениям и временно неопределившиеся,
когда же R# сможет

"Выполнять несколько тестов паралельно"

Здравствуйте, Igor Sukhov, Вы писали:

IS>Здравствуйте, orangy, Вы писали:

IS>я снова сел писать и выполнять тесты,
IS>и поэтому снова:

IS>товарищи, господа, непримкнувшие к первым двум группам по идейным соображениям и временно неопределившиеся,
IS>когда же R# сможет

IS>"Выполнять несколько тестов паралельно"

На Galio c MBUnit не смотрели?

Здравствуйте, xvost, Вы писали:

X>Здравствуйте, nikov, Вы писали:

N>>А если помечать их специальным атрибутом, например [AllowParallelExecution] и сделать, чтобы UTR распознавал его?

X>В данный момент мы поддерживаем NUnit, а не свою доморощенную систему где делай что хочешь.

X>Вот когда старикан Charlie Poole доделает свою мегасистему, то там будет все....

Недолго осталось в NUnit 2.5 beta4 уже включили PNUnit