我有一个 asp.net 核心应用程序,它使用在应用程序的 startup.cs 类中定义的依赖注入:
public void ConfigureServices(IServiceCollection services)
{
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(Configuration["Data:FotballConnection:DefaultConnection"]));
// Repositories
services.AddScoped<IUserRepository, UserRepository>();
services.AddScoped<IUserRoleRepository, UserRoleRepository>();
services.AddScoped<IRoleRepository, RoleRepository>();
services.AddScoped<ILoggingRepository, LoggingRepository>();
// Services
services.AddScoped<IMembershipService, MembershipService>();
services.AddScoped<IEncryptionService, EncryptionService>();
// new repos
services.AddScoped<IMatchService, MatchService>();
services.AddScoped<IMatchRepository, MatchRepository>();
services.AddScoped<IMatchBetRepository, MatchBetRepository>();
services.AddScoped<ITeamRepository, TeamRepository>();
services.AddScoped<IFootballAPI, FootballAPIService>();
这允许这样的事情:
[Route("api/[controller]")]
public class MatchController : AuthorizedController
{
private readonly IMatchService _matchService;
private readonly IMatchRepository _matchRepository;
private readonly IMatchBetRepository _matchBetRepository;
private readonly IUserRepository _userRepository;
private readonly ILoggingRepository _loggingRepository;
public MatchController(IMatchService matchService, IMatchRepository matchRepository, IMatchBetRepository matchBetRepository, ILoggingRepository loggingRepository, IUserRepository userRepository)
{
_matchService = matchService;
_matchRepository = matchRepository;
_matchBetRepository = matchBetRepository;
_userRepository = userRepository;
_loggingRepository = loggingRepository;
}
这非常整洁。但是当我想进行单元测试时成为一个问题。因为我的测试库没有用于设置依赖注入的 startup.cs。因此,具有这些接口作为参数的类将只是空的。
namespace TestLibrary
{
public class FootballAPIService
{
private readonly IMatchRepository _matchRepository;
private readonly ITeamRepository _teamRepository;
public FootballAPIService(IMatchRepository matchRepository, ITeamRepository teamRepository)
{
_matchRepository = matchRepository;
_teamRepository = teamRepository;
在上面的代码中,在测试库中,_matchRepository 和 _teamRepository 将为空。 :(
我可以做类似 ConfigureServices 的事情,在我的测试库项目中定义依赖注入吗?
new SUT(mockDependency);
即可进行测试。
尽管@Kritner 的回答是正确的,但我更喜欢以下代码完整性和更好的 DI 体验:
[TestClass]
public class MatchRepositoryTests
{
private readonly IMatchRepository matchRepository;
public MatchRepositoryTests()
{
var services = new ServiceCollection();
services.AddTransient<IMatchRepository, MatchRepositoryStub>();
var serviceProvider = services.BuildServiceProvider();
matchRepository = serviceProvider.GetService<IMatchRepository>();
}
}
一种简单的方法是,我编写了一个通用的依赖解析器帮助程序类,然后在我的单元测试类中构建了 IWebHost。
通用依赖解析器
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
public class DependencyResolverHelper
{
private readonly IWebHost _webHost;
/// <inheritdoc />
public DependencyResolverHelper(IWebHost webHost) => _webHost = webHost;
public T GetService<T>()
{
var serviceScope = _webHost.Services.CreateScope();
var services = serviceScope.ServiceProvider;
try
{
var scopedService = services.GetRequiredService<T>();
return scopedService;
}
catch (Exception e)
{
Console.WriteLine(e);
throw;
}
}
}
}
单元测试项目:
[TestFixture]
public class DependencyResolverTests
{
private DependencyResolverHelper _serviceProvider;
public DependencyResolverTests()
{
var webHost = WebHost.CreateDefaultBuilder()
.UseStartup<Startup>()
.Build();
_serviceProvider = new DependencyResolverHelper(webHost);
}
[Test]
public void Service_Should_Get_Resolved()
{
//Act
var YourService = _serviceProvider.GetService<IYourService>();
//Assert
Assert.IsNotNull(YourService);
}
}
Once Dispose is called, any scoped services that have been resolved from ServiceProvider will be disposed.
。
.net 核心中的控制器从一开始就考虑到依赖注入,但这并不意味着您需要使用依赖注入容器。
给定一个更简单的类,例如:
public class MyController : Controller
{
private readonly IMyInterface _myInterface;
public MyController(IMyInterface myInterface)
{
_myInterface = myInterface;
}
public JsonResult Get()
{
return Json(_myInterface.Get());
}
}
public interface IMyInterface
{
IEnumerable<MyObject> Get();
}
public class MyClass : IMyInterface
{
public IEnumerable<MyObject> Get()
{
// implementation
}
}
因此,在您的应用程序中,您在 startup.cs
中使用依赖项注入容器,它只是提供 MyClass
的具体化以在遇到 IMyInterface
时使用。然而,这并不意味着它是获取 MyController
实例的唯一方法。
在单元测试场景中,您可以(并且应该)提供您自己的 IMyInterface
实现(或模拟/存根/伪造),如下所示:
public class MyTestClass : IMyInterface
{
public IEnumerable<MyObject> Get()
{
List<MyObject> list = new List<MyObject>();
// populate list
return list;
}
}
在你的测试中:
[TestClass]
public class MyControllerTests
{
MyController _systemUnderTest;
IMyInterface _myInterface;
[TestInitialize]
public void Setup()
{
_myInterface = new MyTestClass();
_systemUnderTest = new MyController(_myInterface);
}
}
所以对于单元测试 MyController
的范围,IMyInterface
的实际实现并不重要(不应该重要),只有接口本身重要。我们提供了 IMyInterface
到 MyTestClass
的“假”实现,但您也可以通过 Moq
或 RhinoMocks
使用模拟来做到这一点。
最重要的是,您实际上并不需要依赖注入容器来完成您的测试,只需要一个单独的、可控的、实现/模拟/存根/假的测试类依赖项。
ServiceCollection
中可用的对象。它对脚手架特别有用,对集成测试也很有帮助……是的,我会在你的测试中使用 DI。
如果您使用 Program.cs
+ Startup.cs
约定并希望快速完成此操作,您可以使用单线重用现有主机构建器:
using MyWebProjectNamespace;
public class MyTests
{
readonly IServiceProvider _services =
Program.CreateHostBuilder(new string[] { }).Build().Services; // one liner
[Test]
public void GetMyTest()
{
var myService = _services.GetRequiredService<IMyService>();
Assert.IsNotNull(myService);
}
}
来自网络项目的示例 Program.cs
文件:
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;
namespace MyWebProjectNamespace
{
public class Program
{
public static void Main(string[] args) =>
CreateHostBuilder(args).Build().Run();
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
}
}
[SetUp]
中设置新的 ServiceCollection 会很有用,甚至可以模拟依赖项。但实际上,我想做的是使用与我的 Web 应用程序相同的服务集合,并针对相同的环境运行测试。干杯!
您可以在测试中使用 asp.net core DI 并注入模拟实例对象。这是一个完整的工作示例:
为了示例:
我只保留了初始问题代码片段中的 IMatchService 依赖项
我在 MatchController 中添加了一个 DoSomething 操作,以便进行一些测试。
我向 IMatchService 和 MatchService 类添加了一个 Add 方法,以便可以模拟一些东西。
请注意,具有 Setup
和 Moq
的方法应该是虚拟的。
[Route("api/[controller]")]
public class MatchController : AuthorizedController
{
private readonly IMatchService _matchService;
public MatchController(IMatchService matchService)
{
_matchService = matchService;
}
public virtual int DoSomething()
{
return _matchService.Add(1, 2);
}
}
public interface IMatchService
{
int Add(int a, int b);
}
public class MatchService : IMatchService
{
public virtual int Add(int a, int b)
{
return a + b;
}
}
始终可以通过调用 Mock.Get
方法来获取 Mock。为了方便每个依赖项,我创建了两个属性,例如 MatchService
和 MockedMatchService
。
public class MyTests
{
protected IMatchService MatchService { get; set; }
protected Mock<IMatchService> MockedMatchService => Mock.Get(MatchService);
private IServiceProvider ServicesProvider { get; set; }
[SetUp]
public void SetupBeforeEachTest()
{
// Configure DI container
ServiceCollection services = new ServiceCollection();
ConfigureServices(services);
ServicesProvider = services.BuildServiceProvider();
// Use DI to get instances of IMatchService
MatchService = ServicesProvider.GetService<IMatchService>();
}
// In this test I mock the Add method of the dependency (IMatchService) so that it returns a value I choose
[Test]
public void TestMethod()
{
// Prepare
var matchController = ServicesProvider.GetService<MatchController>();
int expectedResult = 5;
MockedMatchService.Setup(x => x.Add(It.IsAny<int>(), It.IsAny<int>())).Returns(expectedResult);
// Act - This will call the real DoSomething method because the MatchController has comes from a Mock with CallBase = true
int result = matchController.DoSomething();
// Check
Assert.AreEqual(expectedResult, result);
}
private static void ConfigureServices(IServiceCollection services)
{
services.AddScoped<IMatchService>();
services.AddScoped<MatchController>();
}
}
我研究了@madjack 和@Kritner 的答案,并做出了我的
用于依赖注入的基本可继承基测试类
只需在其中注册您的服务并继承即可。
public class BaseTester
{
protected IProductService _productService;
protected IEmployeeService _employeeService;
public BaseTester()
{
var services = new ServiceCollection();
services.AddTransient<IProductService, ProductService>();
services.AddTransient<IEmployeeService, EmployeeService>();
var serviceProvider = services.BuildServiceProvider();
_productService = serviceProvider.GetService<IProductService>();
_employeeService = serviceProvider.GetService<IEmployeeService>();
}
}
为什么要将它们注入测试类?您通常会测试 MatchController,例如,使用 RhinoMocks 之类的工具来创建存根或模拟。这是一个使用它和 MSTest 的示例,您可以从中推断:
[TestClass]
public class MatchControllerTests
{
private readonly MatchController _sut;
private readonly IMatchService _matchService;
public MatchControllerTests()
{
_matchService = MockRepository.GenerateMock<IMatchService>();
_sut = new ProductController(_matchService);
}
[TestMethod]
public void DoSomething_WithCertainParameters_ShouldDoSomething()
{
_matchService
.Expect(x => x.GetMatches(Arg<string>.Is.Anything))
.Return(new []{new Match()});
_sut.DoSomething();
_matchService.AssertWasCalled(x => x.GetMatches(Arg<string>.Is.Anything);
}
改进的解决方案
我改进了 madjack 的解决方案,将其包装在单个 abstract class
中并添加四个方法(包括两个 async
等效项),并将回调作为参数。 GetRequiredScopedService<TSvc>()
现在使用 private static
属性 services
进行缓存,因此派生类不会一遍又一遍地创建新实例。另一个优化是制作 host
static
,所以我们不会每次都在派生类中构建它。我还删除了无意义的 try/catch:
public abstract class TestWithDependencyInjection
{
private static readonly IHost host =
Program.CreateHostBuilder(Constants.CommandArgs).Build();
private static readonly IList<object> services =
new List<object>();
private IServiceScope svcScope;
protected async Task<TResult> UseSvcAsync<TSvc, TResult>(
Func<TSvc, Task<TResult>> callback,
bool shouldBeDisposed = true)
{
var scopedSvc = GetRequiredScopedService<TSvc>();
TResult result = await callback(scopedSvc);
if(shouldBeDisposed)
svcScope.Dispose();
return result;
}
protected async Task UseSvcAsync<TSvc>(
Func<TSvc, Task> callback)
{
var scopedSvc = GetRequiredScopedService<TSvc>();
await callback(scopedSvc);
svcScope.Dispose();
}
protected TResult UseSvc<TSvc, TResult>(
Func<TSvc, TResult> callback, bool shouldBeDisposed = true)
{
var scopedSvc = GetRequiredScopedService<TSvc>();
TResult result = callback(scopedSvc);
if(shouldBeDisposed)
svcScope.Dispose();
return result;
}
protected void UseSvc<TSvc>(Action<TSvc> callback)
{
var scopedSvc = GetRequiredScopedService<TSvc>();
callback(scopedSvc);
svcScope.Dispose();
}
private TSvc GetRequiredScopedService<TSvc>()
{
var requiredScopedSvc = (TSvc)services.SingleOrDefault(
svc => svc is TSvc);
if (requiredScopedSvc != null)
return requiredScopedSvc;
svcScope = host.Services.CreateScope();
requiredScopedSvc = svcScope.ServiceProvider
.GetRequiredService<TSvc>();
services.Add(requiredScopedSvc);
return requiredScopedSvc;
}
}
从使用的注入服务返回异步结果的示例:
int foobarsCount = await UseSvcAsync<IFoobarSvc, int>(
foobarSvc => foobarSvc.GetCountAsync());
附加信息
我将 true
上的可选 shouldBeDisposed
参数集添加到返回 TResult
和 Task<TResult>
的方法中,以防万一您想在回调主体之外使用相同的服务实例:
IFoobarSvc foobarSvc = UseSvc<IFoobarSvc, IFoobarSvc>(
foobarSvc => foobarSvc, false);
不定期副业成功案例分享
GetService<>
有一些可以通过using Microsoft.Extensions.DependencyInjection
找到的重载