Избегайте использования общей памяти между интеграционными тестами ASP.NET Core

WebApplicationFactory для минимального хостинга в основном запускается Assembly.EntryPoint для каждого экземпляра экземпляра фабрики (который является вашим Main методом), следовательно, ваш a++; будет вызываться для каждого созданного и «запущенного» экземпляра фабрики (он включает в себя такие вызовы, как CreateClient или Services или Server), а поскольку a является статическим полем, оно будет использоваться на протяжении всей жизни приложения (в основном по определению).

Есть как минимум следующие варианты:

1. Перейдите от использования статики к одноэлементным сервисам. Т.е. инкапсулируйте a в какой-нибудь сервис, зарегистрируйте его как синглтон и разрешите, где это необходимо. Возможно, это лучший подход в общем случае.

2. Используйте один экземпляр WebApplicationFactory для всех тестов (чтобы настройка выполнялась только один раз). Например, используя OneTimeSetUp в сочетании с корневым приспособлением. Например, добавьте что-то вроде следующего в корневое пространство имен тестового проекта (см. документацию SetUpFixture):

   [SetUpFixture]
   public class GlobalFixture
   {
       public static WebApplicationFactory<Program> ApplicationFactory;
   
       [OneTimeSetUp]
       public void Setup() => ApplicationFactory = new WebApplicationFactory<Program>();
   
       [OneTimeTearDown] 
       public void TearDown() => ApplicationFactory.Dispose();
   }
   

   И используйте GlobalFixture.ApplicationFactory там, где это необходимо.

3. В некоторых случаях вы можете обойти это, переместив управление a в статический конструктор (добавьте его в свой Program класс).

4. Другой хакерский подход — изменить точку входа (Program.Main) с помощью некоторой условной логики (возможно, путем введения другого статического поля), например if (a == 0) a++;.

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

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

Может быть, это как-то связано с тем, что я использую NUnit вместо xUnit, как указано в документации? Но тогда как на это влияет поведение NUnit?

Как видите, это не NUnit как таковой.

Вы уже используете одно веб-приложение для каждого теста.

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

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

Я бы посоветовал вам продолжать использовать веб-приложение для каждого теста, поскольку это обеспечивает лучшую изоляцию. Я бы просто переместил код в методы [SetUp] и [TearDown], если вы хотите его немного почистить. И, возможно, также добавьте это в свой класс: [FixtureLifeCycle(LifeCycle.InstancePerTestCase)].

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

Итак, реальная проблема здесь заключается в следующем: как «сбросить» эти статические объекты детерминированным способом?

Как уже упоминалось, все ваши тесты выполняются в одном и том же домене приложения, поэтому нет возможности сбросить их в конце процесса. Вам необходимо вручную сбросить объекты до их значений по умолчанию или любого другого значения. Есть много способов добиться этого, как указано в других ответах. Еще один довольно общий, но грязный способ — использовать отражение, чтобы получить доступ к переменным static и установить для них все, что захотите.

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

[TearDown] // will be executed after every test
public void TearDown()
{
    var a = typeof(Program).GetField("a", BindingFlags.Static | BindingFlags.NonPublic);
    a.SetValue(null, default(int));
}

Однако тест очень хрупкий. Как только вы переименуете статическую переменную или измените ее на свойство, сделаете ее internal или что-то еще, ваши тесты потерпят неудачу. Поэтому вам следует подумать о рефакторинге вашего кода, чтобы каким-то образом внедрить ваши зависимости извне, используя ваш DI-контейнер. Вам также следует подумать о том, чтобы скрыть эти грязные строки в каком-нибудь SetupTest-методе, который вы сможете переписать как можно скорее.