We are setting data which is not in the scope of this method. These values are not used in the GenerateBill method. Observe carefully the data being setup in the test like the customer type and the billed amount. If we look at the tests they are testing the wrong thing. This ensures that we haven’t broken any of the existing functionality.
If we run the unit tests after this refactoring, they still run as expected. PhoneBill generateBill = GetGenerateBillWithDefaultValues ( customer ) ĬalculateDiscount ( customer, generateBill ) ĬalculateTotalDueAmount ( generateBill ) Īfter this refactoring, the GenerateBill method acts as template method which calls other methods. Public PhoneBill GenerateBill ( Customer customer )
#RHINO MOCKS CODE#
Instead of going through step by step refactoring, I’ll directly show the final code snippet. Same is the case with the final part which computes the total due amount. It would be nice to refactor this into a separate method. The first part which copies the values from customer to bill entity is common to all types of customers. We can refactor the if else block into a switch case statement. In its current state, the GenerateBill method only works for Normal and Corporate customers. Lets refactor the code to suite this requirement. The discount varies for newly added types which are Gold, Silver and Platinum. Based on various factors which are outside the scope of this post lets say the customers are classified as Normal, Corporate, Gold, Silver and Platinum. The phone company has come up with more classifications for the customers.
#RHINO MOCKS UPDATE#
Imagine there is an update to the original user requirement. Because this post is related to Partial mocks, lets create a scenario which forces us to make use of Rhino mocks. Both the tests are pretty straightforward. And the second test validates that the customer is given his due 25% discount on the original billed amount. The first one which tests that there is no discount applied for the Normal customer’s total due amount. Private static Customer CreateCustomer ( string customerType, double billedAmount ) Public void GenerateBill_WithCustomerTypeAsCorporate_Appl圜orporateDiscountOnTotalBilledAmount ()Ĭustomer customer = CreateCustomer ( "Corporate", 170.50 ) Īssert. PhoneBillCalculator billCalculator = new PhoneBillCalculator () Public void GenerateBill_WithCustomerTypeAsNormal_ApplyNoDiscountOnTotalBilledAmount ()Ĭustomer customer = CreateCustomer ( "Normal", 170.50 ) While calculating the total due amount for a customer, the phone company does not give any discount for the normal customers but corporate customers are eligible for the 25% discount on the billed amount. The Normal ones and the Corporate customers. As of now the company has two types of customers. Lets assume we are building a solution for calculating the phone bill for a hypothetical phone company. It can be used to also test methods by mocking only the methods we are interested in. But that's not the only use of Partial mock. As mentioned in the documentation of the Rhino mocks, my understanding of the partial mock was that it is used to mock the abstract classes and methods. Most of the time I have relied on using Strict mock and stubs. Recently I had a wow moment when I found a real use of the Partial mock. The use of these types for specific use is bit confusing. It has support for different types of mocks like Strict mocks, Dynamic mocks and Partial mocks. I have been using Rhino Mocks for past couple of years as the Dynamic mocking framework.
0 kommentar(er)
