The document provides an overview of unit testing and dependency injection using Entity Framework. It discusses how to achieve true unit testing through dependency injection and mocking dependencies. It provides examples of how to set up interfaces, manager classes, context classes and writing unit tests using Rhino Mocks and MSTest. Code coverage is also discussed as an important part of unit testing.
31. Comparison between RhinoMock, Moq, NMock2 and TypeMock Ease of use Cost Likes Dislikes Rhino Mocks Easy due to being strongly-typed, which makes the syntax great and "safe". Free Strongly typed instancing - no need to use string references. Full AAA support Record / Replay should be implied not expected. Moq Doesn’t use record / replay scenarios! similar to Rhino Mocks Free Similar to Rhino Mocks, with no support for record / replay Creates wrapper of mock instance. NMock Use of strings to call property methods / normal methods. Free Pales to insignificance in contrast to RhinoMocks, Moq or TypeMock Need to use string declarations for instancing. Type Mock Extremely easy to implement mocking because it uses the .NET framework profiler API to monitor an application's execution. Expensive The fact that it "plugs-in" to the CLR and captures type references, means that no code changes need to be done on legacy components. Prohibitively Expensive.
Editor's Notes
Unit Tests are written to test an individual unit of code in isolation, “stubbing out” or “mocking” dependant resources that exist outside the domain of the code being tested (including but not limited to Database or Configuration Files) Integration Tests are written to test “across code boundaries or architectural layers”; they should test as much of the code stack as feasibly possible, from UI to Data resource.
Imagine going to a restaurant with a bunch of your friends. there are some couples there as well as singles. At the end of the meal, it is time to pay. Unit testing is like giving a separate bill to each couple or individual. Each person knows only what they need to pay as well as tip, but do not care what anyone else had, or what the total meal amount is; as long as they pay what they need, they can go home peacefully. Integration testing is like giving one big check to the group, with everyone having to calculate on their own how much they need to pay. Sometimes everyone thinks that it works out, but in the end the total amount may be too high or too low. There is a lot of interaction going on to decide who pays for what and who has already paid. And often some will pay more for what they actually had than if they got their own individual bill.
Dependency Injection is a design pattern based on the theory of “separation of concerns”. An object instance will have its resource-based member variables (database connectivity, file system interaction, etc) [ Dependency ] set by an external entity [ Injection ] Often referred to as IoC (Inversion of Control) – a common mistake made – IoC is a container/implementation of the Dependency Injection pattern.
With Setter Injection it is not clear in which order things need to be instantiated and when the wiring is done
Contrast the “Base” (Before) solution and the “UsingDi” (After) solution. Starting with the Manager classes, notice how the test methods call on the actual isntance of the Manager class and mock out the Dependency. Rhino Mocks works with AAA (Arrange, Act, Assert) so we setup the test and the expectations, call the method and assert the results.
Executing a complete build we can view the code coverage results (using the “UsingDi” (After) solution)