Remember that time (yesterday) when I created my own fake implementations for my tests? Man, was I crazy.
There is an awesome library called FakeItEasy, which ease up your fake implementations.
Now, instead of implementing your own IEntitiesContainer (or whatever your data layer injection interface is), you can tell FakeItEasy to generate a new fake of this interface, and you get a bunch of assertion methods on it thrown in for good measure.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
private readonly OrdersController controller; private readonly IEntitiesContainer fakeContainer; public CommandesControllerTests() { // use a fake of the interface to inject in the controller this.fakeContainer = A.Fake<IEntitiesContainer>(); this.controller = new OrdersController(this.fakeContainer); } [Fact] public void Controller_gets_single_item() { // arrange: the GetOrder method with whatever parameter will return something A.CallTo(() => this.fakeContainer.GetOrder(A<int>.Ignored)).Returns(new OrderDto()); // act OrderDto result = this.controller.GetOrders(0); // assert: make sure the underlying IEntitiesContainer's proper method has been called result.Should().NotBeNull("because the method should fetch an item"); A.CallTo(() => this.fakeContainer.GetOrder(A<int>.Ignored)).MustHaveHappened(); } |
It also helps you make sure you’re testing the right things. For instance, I had a test method return a list of paginated result, and went to great lengths to make sure the proper number of items were returned. After spending a bit of time trying to refactor my test (because FakeItEasy doesn’t make it easy to provide specific parameters), I found out I don’t care about the number of returned results, since this is tested elsewhere.