Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Dependency Injection & Unit Testing

Chris Ayers
February 19, 2019

Dependency Injection & Unit Testing

A dive into dependency injection in traditional .Net applications and ASP.Net Core. Followed by how dependency injection enables unit testing in .Net core and EF core. Code examples of how to unit test at the controller, service, and data layers.

Chris Ayers

February 19, 2019
Tweet

More Decks by Chris Ayers

Other Decks in Technology

Transcript

  1. Topics • Dependency Injection • Why? • SOLID • Design

    Patterns • Types • Features • DEMO • Unit Testing • Terms • Test Layout and Naming • Mocking • Best Practices • DEMO
  2. Why? • Clarity • Maintainability • Reuseability • Modularity •

    Testability • Use Different Implementations
  3. SOLID • Single Responsibility Principle • Open/Closed Principle • Liskov

    Substituion Principle • Interface Segregation Principle • Dependency Inversion Principle
  4. No Dependency Injection • Not using interfaces to reduce coupling

    • Hard to test • No clear understanding of relationships between different classes
  5. Dependency Injection - Frameworks .Net Core .Net Core Unity Unity

    Castle Windsor Castle Windsor Ninject Ninject AutoFac AutoFac SimpleInjector SimpleInjector Spring.NET Spring.NET StructureMap StructureMap
  6. Decoupling is essential for unit testing. DI is a great

    way to achieve decoupling. Dependency Injection + Unit Testing
  7. Unit Testing – Terms (SUT) System Under Test or (CUT)

    Class Under Test Test Doubles Fake Mock Stub Spy Dummy Objects
  8. Unit Testing - Architectures • Easy to Test Code •

    Inversion of Control (IoC) • Interface Segregation • Functional Programming • Hard to Test code • It is tightly coupled to the concrete implementation. • It violates the Single Responsibility Principle. • It lies about its dependencies. • It is hard to understand and maintain.
  9. Unit Testing - Layout Split up tests by assembly/project. •

    Ex: if you have two libraries: foo.dll, bar.dll • have 2 unit test assemblies: foo.tests.dll, bar.tests.dll Try to have at least 1 test class per class • Ex: if you have two classes in project foo: a.cs, b.cs • have 2 unit test classes in project foo.tests: aTests.cs, bTests.cs • If there are a lot of methods, or tests for some methods, split it up if there are a too many tests in one class. Use folders to mirror layout and namespaces of target project
  10. Unit Testing - Naming Name test class for the class

    under test • Foo.cs -> FooTests.cs [UnitOfWork_StateUnderTest_ExpectedBehavior] Examples • public void GetLines_twoLineString_returnsTwoStrings() • public void GetNonWhitespaceLines_null_Throws() • public void ReplaceMultiple_stringWithHashNonMatchingMappings_String() • public void ReplaceMultiple_stringMatchingMappings_UpdatedString()
  11. Unit Testing – Gotchas Usually only works for Interfaces or

    Virtual Methods. Statics can be difficult, refactoring can help or Microsoft Fakes Mocking can make assumptions about boundaries
  12. Unit Testing – Best Practices AAA Arrange Act Assert One

    Assert Per Test Method Avoid Test Interdependence Keep It Short, Sweet, and Visible Recognize Test Setup Pain as a Smell Add Them to the Build
  13. Unit Testing – What is a good test? Fast Fast

    Isolated Isolated Repeatable Repeatable Self- Checking Self- Checking Timely Timely