Как разделить многотестную dll на отдельные dll для каждого TestClass для распараллеливания мультиагентного тестирования DevOps Azure - PullRequest
Новая
       51

Как разделить многотестную dll на отдельные dll для каждого TestClass для распараллеливания мультиагентного тестирования DevOps Azure

0 голосов
/ 10 июня 2019

Azure DevOps имеет возможность запускать тесты Visual Studio для нескольких агентов параллельно .Я хотел бы воспользоваться этим, но когда я обновил свой конвейер сборки для работы с несколькими агентами со стратегией Based on past running time of tests, каждому агенту назначается как минимум одна вся тестовая сборка (т. Е. TestSuite1.dll,TestSuite2.dll и т. Д.).Это означает, что существует огромная возможность распараллелить потерянный для каждого из наших независимых MSTest TestClass, потому что наши тесты были разработаны с областью выполнения на уровне класса.

Наш конвейер Azure DevOps успешно выполняется с распараллеливаниеммежду агентами на базовую тестовую сборку, но, очевидно, мы бы предпочли нарезку на каждый отдельный тест в нашей тестовой сборке, поэтому какова лучшая стратегия для достижения разделения каждого производного TestClass по агентам (желательно без рефакторинга всего нашего тестового кода))?

Примечания:

Я сгенерировал xml, чтобы «успешно» встроить ровно один TestClass в свой собственный .dll, а затем сослаться только на этот .dll в задаче Visual Studio Test,но существует просто ассамблея bazillion, ссылающаяся на проблемы \ redirect, когда фактический класс начинает выполняться после кода [AssemblyInitialize].Поскольку у меня есть выходные данные сборки для всего нашего решения, у меня есть доступ к команде csc, запускаемой для всей тестовой сборки, но, опять же, я еще не смог ее протестировать, и я предполагаю, что просто ссылаюсь на параметры конфигурации в нейбудет хрупким для будущих изменений.Кроме того, я не думаю, что выполнение задачи Visual Studio Test с чем-либо, кроме Select tests using Test Assemblies, даст преимущество стратегии нарезки Based on past running time of tests.

1 Ответ

0 голосов
/ 11 июня 2019

Динамическое создание тестовых сборок кажется сумасшедшим, но вы могли бы переместить всю базовую логику сантехники в сборку «каркас тестирования», а затем программно генерировать тестовые сборки для каждого TestClass: 

csc TestClassName.cs -reference:TestFramework.dll

Или ...

Вместо того, чтобы пытаться реорганизовать тесты программным способом, возможно, имеет смысл разделить тесты вручную на разные логические группы. В идеале вы бы разбили их на пространство имен или другую важную границу. Теоретически вы также можете реорганизовать их в произвольные сегменты (быстрый / медленный или 0,1,2,3) и переместить тестовые классы равной длительности в соответствующий блок для достижения желаемого временного баланса. Например (Namespace.0.Tests.dll, Namespace.1.Tests.dll, Namespace.2.Tests.dll) По общему признанию пострадает обнаружимость модульных тестов.

Или ....

Здесь действует совет «Непрерывная доставка Jez Humble»: «если это больно, делай это чаще». То, что вы описываете, звучит больно, и вы должны углубляться в эту боль, а не пытаться решить ее с большей болью (например, топать ногой, чтобы облегчить удар локтем).

Команда разработчиков Azure пережила аналогичную революцию: у них было несколько тестов с использованием TestHarness, от которых они хотели отказаться. Они пометили все свои устаревшие тесты и составили долгосрочную стратегию по переходу от этой модели к установленной дате. Ваш подход может быть похожим:

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

  2. Переместите все, что можете, в вышеприведенную сборку. Во всем остальном планируйте перенести их на более поздний срок.

  3. Отчет о ходе работы с KPI: длина сборки, количество тестов с использованием старой платформы. Затем повторяйте 1 и 2, пока вы не решите проблему с помощью более эффективной модели.

...