Now you can argue that this is a bad practice, that the object composition should be handled in a different manner, as usually in this cases the single responsibility principle is not met. What this method does in particular is composing another object that will be passed to our dependency, the order repository. More precisely we are going to write unit tests for the GetProducts method. What you can see here is a hypothetical product service that we are going to test. Order retrievedOrder = m_orderRepository.GetOrder(orderSearchCriteria) OrderId = customerId // THIS IS THE PROBLEM WE ARE GOING TO SEARCH FOR OrderSearchCriteria orderSearchCriteria = new OrderSearchCriteria Public List GetProducts(int customerId, int orderId) Public ProductService(IOrderRepository orderRepository) Private readonly IOrderRepository m_orderRepository
As code speaks more than thousand words, let’s illustrate this with an example. However, it ain’t that simple and straightforward as it seems.
In this case we need to verify that this transformation did what we expected it to do. This kind of situations are commonly found in all the cases in which the tested unit manipulates the arguments that are passed to our mock. This is what pushed me to write this post and describe this kind of situations and a decent solution to it. As a result, code coverage is dropping down, unverified logics are shown up, lowering the quality and rising frustrations. More and more often I do see people having trouble testing certain type of code.
0 kommentar(er)
