Каждый из моих тестовых проектов XUnit имеет файл appsettings.json, в котором указаны некоторые параметры. Я всегда использовал внедрение зависимостей с помощью IConfiguration, чтобы получить эти настройки в моем классе Test Fixture. Теперь, когда я думаю об этом, я совершенно не понимаю, как IConfiguration решалась в прошлом, поскольку в проекте XUnit нет методов Startup.cs и ConfigureServices. Но клянусь, это сработало.
Раньше работало, а теперь нет:
Крепление:
public class TestFixture : IDisposable
{
public IConfiguration Configuration { get; set; }
public TestFixture(IConfiguration configuration)
{
Configuration = configuration;
}
}
Тестовый класс:
public class TestCases : IClassFixture<TestFixture>
{
public TestCases(TestFixture fixture)
{
}
}
Я получаю следующую ошибку:
Message: System.AggregateException : One or more errors occurred. ---- Class fixture type 'MyProj.Tests.TestFixture' had one or more unresolved constructor arguments: IConfiguration configuration ---- The following constructor parameters did not have matching fixture data: TestFixture fixture
@RubenBartelink Вам кажется странным, что он как-то работал раньше и не работает сейчас из-за последней версии XUnit или .NET Core 2.0?
Определенно есть что-то странное, но я не могу придумать никаких причин полагать, что был какой-то момент времени, когда xUnit создавал что-то, кроме того, что продиктовано явным использованием IClassFixture
и / или CollectionAttribute
. Единственное, что приходит мне в голову, это конструкторы по умолчанию, скрывающие зависимости и / или тестовые классы, которые являются частными и т. д., Но предположим, что что-то сработало для вас, поэтому это должно быть что-то еще
Интересно, почему у меня был такой код, как вы, поскольку в документации (https://xunit.github.io/docs/shared-context) ничего не говорится об использовании DI в Fixtures ... В моем случае я решил это, удалив DI, потому что у меня была та же ошибка, что и у вас.
Затем у меня есть такой код для коллекции сервисов для модульных тестов.
var services = new ServiceCollection();
ConfigureServices(services);
IServiceProvider serviceProvider = services.BuildServiceProvider();
// Assign shortcuts accessors to registered components
UserManager = serviceProvider.GetRequiredService<UserManager<User>>();
RoleManager = serviceProvider.GetRequiredService<RoleManager<IdentityRole<string>>>();
My ConfigureServices () вызывает этот код перед регистрацией служб для сбора, поэтому он отвечает на ваш вопрос об IConfiguration. Обратите внимание, что сейчас я использую .net core 2.1, раньше было 2.0. Но мне все еще интересно, как и вам и другим людям, которые комментировали, почему DI не вылетал раньше?
private static IConfiguration LoadConfiguration()
{
var builder = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json");
return builder.Build();
}
как думаешь, сможешь ответить на этот вопрос? Спасибо stackoverflow.com/questions/57331395/…
Связанный пост от @ Tom85Morris очень интересен!
Очевидно, это технически возможно, но крайне маловероятно; люди из xUnit сделали множество заявлений о том, что нет никакого плана или желания делать общий DI как здесь, так и по вопросам Github.