Using DI container in unit tests

by

For true unit tests (i.e. those which only test one class, and mock all of its dependencies), it doesn’t make any sense to use a DI framework. In these tests:

  • if you find that you have a lot of repetitive code for newing up an instance of your class with all the mocks you’ve created, one useful strategy is to create all of your mocks and create the instance for the subject-under-test in your Setup method (these can all be private instance fields), and then each individual test’s “arrange” area just has to call the appropriate Setup() code on the methods it needs to mock. This way, you end up with only one new PersonController(...) statement per test class.
  • if you’re needing to create a lot of domain/data objects, it’s useful to create Builder objects that start with sane values for testing. So instead of invoking a huge constructor all over your code, with a bunch of fake values, you’re mostly just calling, e.g., var person = new PersonBuilder().Build(), possibly with just a few chained method calls for pieces of data that you specifically care about in that test. You may also be interested in AutoFixture, but I’ve never used it so I can’t vouch for it.

If you’re writing integration tests, where you need to test the interaction between several parts of the system, but you still need to be able to mock specific pieces, consider creating Builder classes for your services, so you can say, e.g. var personController = new PersonControllerBuilder.WithRealDatabase(connection).WithAuthorization(new AllowAllAuthorizationService()).Build().

If you’re writing end-to-end, or “scenario” tests, where you need to test the whole system, then it makes sense to set up your DI framework, leveraging the same configuration code that your real product uses. You can alter the configuration slightly to give yourself better programmatic control over things like which user is logged in and such. You can still leverage the other builder classes you’ve created for constructing data, too.

var user = new PersonBuilder().Build();
using(Login.As(user))
{
     var controller = Container.Get<PersonController>();
     var result = controller.GetCurrentUser();
     Assert.AreEqual(result.Username, user.Username)
}

More Related Contents:

  1. How to avoid Dependency Injection constructor madness?
  2. How do the major C# DI/IoC frameworks compare? [closed]
  3. Simple Injector unable to inject dependencies in Web API controllers
  4. .NET Core DI, ways of passing parameters to constructor
  5. Dependency injection with a static logger, static helper class
  6. Unit Testing File I/O
  7. log4net with DI Simple Injector
  8. Simple Injector: Register ILogger by using ILoggerFactory.CreateLogger()
  9. Constructor injection with Quartz.NET and Simple Injector
  10. Dependency Injection and the Strategy Pattern
  11. Mock HttpContext.Current in Test Init Method
  12. Dependency Injection in attributes
  13. Dependency Injection Unity – Conditional Resolving
  14. How to mock an async repository with Entity Framework Core
  15. Making a private method public to unit test it…good idea?
  16. How to mock static methods in c# using MOQ framework?
  17. Can a unit test project load the target application’s app.config file?
  18. How to check if a list is ordered?
  19. How to inject dependency to static class
  20. Use dependency injection in static class
  21. Using Moq to mock an asynchronous method for a unit test
  22. Using a Strategy and Factory Pattern with Dependency Injection
  23. The provider for the source IQueryable doesn’t implement IAsyncQueryProvider
  24. NSubstitute – Testing for a specific linq expression
  25. MSTest cannot find the assembly
  26. How to register Windows Forms with Simple Injector
  27. How can I get “Copy to Output Directory” to work with Unit Tests?
  28. Is it possible to bind different interfaces to the same instance of a class implementing all of them?
  29. Using Moq to override virtual methods in the same class
  30. Xamarin (Android) Unit Tests in Visual Studio 2017

Leave a Comment