Виконувати модульні тести послідовно (а не паралельно)

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

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

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

ПРИМІТКА. ServiceHost - це клас WCF, написаний Microsoft. У мене немає можливості змінити свою поведінку. Хостинг кожної кінцевої точки служби лише один раз - це також правильна поведінка ... однак, це не особливо сприяє модульному тестуванню.

Кожен тестовий клас - це унікальна колекція тестів, і тести під ним будуть виконуватися послідовно, тому, якщо ви помістите всі свої тести в одну колекцію, вона буде виконуватися послідовно.

Для досягнення цього в xUnit можна внести такі зміни:

Паралельно буде виконуватися:

namespace IntegrationTests
{
    public class Class1
    {
        [Fact]
        public void Test1()
        {
            Console.WriteLine("Test1 called");
        }

        [Fact]
        public void Test2()
        {
            Console.WriteLine("Test2 called");
        }
    }

    public class Class2
    {
        [Fact]
        public void Test3()
        {
            Console.WriteLine("Test3 called");
        }

        [Fact]
        public void Test4()
        {
            Console.WriteLine("Test4 called");
        }
    }
}

Щоб зробити його послідовним, вам просто потрібно помістити обидва тестові класи в одну колекцію:

namespace IntegrationTests
{
    [Collection("Sequential")]
    public class Class1
    {
        [Fact]
        public void Test1()
        {
            Console.WriteLine("Test1 called");
        }

        [Fact]
        public void Test2()
        {
            Console.WriteLine("Test2 called");
        }
    }

    [Collection("Sequential")]
    public class Class2
    {
        [Fact]
        public void Test3()
        {
            Console.WriteLine("Test3 called");
        }

        [Fact]
        public void Test4()
        {
            Console.WriteLine("Test4 called");
        }
    }
}

Для отримання додаткової інформації ви можете звернутися за цим посиланням

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

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

За замовчуванням xUnit 2.x запускає всі тести паралельно. Це можна змінити для кожної збірки, визначивши CollectionBehaviorу своєму AssemblyInfo.cs у вашому тестовому проекті.

Для розділення в зборі:

using Xunit;
[assembly: CollectionBehavior(CollectionBehavior.CollectionPerAssembly)]

або взагалі не використовуйте розпаралелювання:

[assembly: CollectionBehavior(DisableTestParallelization = true)]

Остання, мабуть, та, яку ви хочете. Більше інформації про розпаралелювання та конфігурацію можна знайти в документації xUnit .

Для проектів .NET Core створіть за xunit.runner.jsonдопомогою:

{
  "parallelizeAssembly": false,
  "parallelizeTestCollections": false
}

Крім того, ви csprojповинні містити

<ItemGroup>
  <None Update="xunit.runner.json"> 
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </None>
</ItemGroup>

Для старих проектів .Net Core ви project.jsonповинні містити

"buildOptions": {
  "copyToOutput": {
    "include": [ "xunit.runner.json" ]
  }
}

Для проектів .NET Core ви можете налаштувати xUnit із xunit.runner.jsonфайлом, як це вказано на https://xunit.github.io/docs/configuring-with-json.html .

Налаштування, яке потрібно змінити, щоб зупинити паралельне виконання тесту, має parallelizeTestCollectionsзначення за замовчуванням true:

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

Тип схеми JSON: логічне
значення Значення за замовчуванням:true

Тож мінімум xunit.runner.jsonдля цієї мети виглядає

{
    "parallelizeTestCollections": false
}

Як зазначено в документах, не забудьте включити цей файл у свою збірку, або:

• Налаштування Копіювати у вихідний каталог для копіювання, якщо воно нове у властивостях файлу у Visual Studio, або

• Додавання

  <Content Include=".\xunit.runner.json">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </Content>

  до вашого .csprojфайлу, або

• Додавання

  "buildOptions": {
    "copyToOutput": {
      "include": [ "xunit.runner.json" ]
    }
  }

  до вашого project.jsonфайлу

залежно від типу вашого проекту.

Нарешті, на додаток до вищесказаного, якщо ви використовуєте Visual Studio, переконайтеся, що ви випадково не натиснули кнопку Виконати тести в паралелі , що призведе до паралельного запуску тестів, навіть якщо ви вимкнули паралелізацію в xunit.runner.json. Розробники інтерфейсу Microsoft хитро зробили цю кнопку без позначень, важко помітити, і приблизно на сантиметр від кнопки "Запустити все" в Провіднику тестів, щоб максимізувати шанс, що ви вдарите її помилково і не уявляєте, чому ваші тести раптом не вдаються:

Це старе питання, але я хотів написати рішення для людей, які шукають нещодавно, як я :)

Примітка: Я використовую цей метод у тестах інтеграції Dot Net Core WebUI з xunit версії 2.4.1.

Створіть порожній клас з ім'ям NonParallelCollectionDefinitionClass, а потім надайте атрибуту CollectionDefinition цьому класу, як показано нижче. (Важливою частиною є DisableParallelization = true.)

using Xunit;

namespace WebUI.IntegrationTests.Common
{
    [CollectionDefinition("Non-Parallel Collection", DisableParallelization = true)]
    public class NonParallelCollectionDefinitionClass
    {
    }
}

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

namespace WebUI.IntegrationTests.Controllers.Users
{
    [Collection("Non-Parallel Collection")]
    public class ChangePassword : IClassFixture<CustomWebApplicationFactory<Startup>>
    ...

Коли ми робимо це, спочатку запускаються інші паралельні тести. Після цього запускаються інші тести, які мають атрибут Collection ("Непаралельне збір").

Ви можете використовувати список відтворення

клацніть правою кнопкою миші на тестовому методі -> Додати до списку відтворення -> Новий список відтворення

тоді ви можете вказати порядок виконання, за замовчуванням це, коли ви додаєте їх до списку відтворення, але ви можете змінювати файл списку відтворення як завгодно

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

• Клас читання конфігурації
• Завод ServiceHost (можливо, як тест інтеграції)
• Клас двигуна, який приймає IServiceHostFactoryіIConfiguration

Інструменти, які могли б допомогти, включають ізоляційні (знущальні) фреймворки та (за бажанням) фреймворки контейнерів IoC. Побачити:

• http://www.mockobjects.com/
• http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

Можливо, ви можете скористатись розширеним модульним тестуванням . Це дозволяє визначити послідовність, в якій ви запускаєте тест . Тож, можливо, доведеться створити новий файл cs для розміщення цих тестів.

Ось як ви можете зігнути методи тестування для роботи в потрібній послідовності.

[Test]
[Sequence(16)]
[Requires("POConstructor")]
[Requires("WorkOrderConstructor")]
public void ClosePO()
{
  po.Close();

  // one charge slip should be added to both work orders

  Assertion.Assert(wo1.ChargeSlipCount==1,
    "First work order: ChargeSlipCount not 1.");
  Assertion.Assert(wo2.ChargeSlipCount==1,
    "Second work order: ChargeSlipCount not 1.");
  ...
}

Повідомте мене, чи це працює.

Для мене, у програмі .Net Core Console, коли я хотів синхронно запускати методи тестування (а не класи), єдиним рішенням, яке спрацювало, було це, описане в цьому блозі: xUnit: Контроль порядку виконання тесту

Я додав атрибут [Collection ("Sequential")] в базовий клас:

    namespace IntegrationTests
    {
      [Collection("Sequential")]
      public class SequentialTest : IDisposable
      ...


      public class TestClass1 : SequentialTest
      {
      ...
      }

      public class TestClass2 : SequentialTest
      {
      ...
      }
    }

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

public class TestClass
{
    [Fact]
    void Test1()
    {
        lock (this)
        {
            //Test Code
        }
    }

    [Fact]
    void Test2()
    {
        lock (this)
        {
            //Test Code
        }
    }
}