Writing tests for services with lots of collaborators can be tedious. I know! We will end up with complex Arrange parts and lots of fakes. Let’s see three alternatives to write simpler tests with builder methods, Type Builders and AutoFixture.
To write simpler tests for services with lots of collaborators, use builder methods to create only the fakes needed in every test. As an alternative, use auto-mocking to create a service with its collaborators replaced by test doubles.
To show these three alternatives, let’s bring back our OrderService class. We used it to show the difference between stubs and mocks. Again, the OrderService checks if an item has stock available to then charge a credit card.
This time, let’s add an IDeliveryService to create a shipment order and an IOrderRepository to keep track of order status. With these two changes, our OrderService will look like this:
publicclassOrderService{privatereadonlyIPaymentGateway_paymentGateway;privatereadonlyIStockService_stockService;privatereadonlyIDeliveryService_deliveryService;privatereadonlyIOrderRepository_orderRepository;publicOrderService(IPaymentGatewaypaymentGateway,IStockServicestockService,IDeliveryServicedeliveryService,IOrderRepositoryorderRepository){_paymentGateway=paymentGateway;_stockService=stockService;_deliveryService=deliveryService;_orderRepository=orderRepository;}publicOrderResultPlaceOrder(Orderorder){if(!_stockService.IsStockAvailable(order)){thrownewOutOfStockException();}// Process payment, ship items, and store order status...returnnewPlaceOrderResult(order);}}
I know, I know! We could argue our OrderService is doing a lot of things! Bear with me.
Let’s write a test to check if the payment gateway is called when we place an order. We’re using Moq to write fakes. This test will look like this:
Sometimes, we need to create fakes for our collaborators even when the behavior under test doesn’t need them.
1. Builder methods
One easy alternative to writing simpler tests is to use builder methods.
With a builder method, we only create the fakes we need inside our tests. And, inside the builder method, we create “empty” fakes for the collaborators we don’t need for the tested scenario.
usingMicrosoft.VisualStudio.TestTools.UnitTesting;usingMoq;namespaceWithABuilderMethod;[TestClass]publicclassOrderServiceTestsBuilder{[TestMethod]publicvoidPlaceOrder_ItemInStock_CallsPaymentGateway(){varstockService=newMock<IStockService>();stockService.Setup(t=>t.IsStockAvailable(It.IsAny<Order>())).Returns(true);varpaymentGateway=newMock<IPaymentGateway>();varorderService=MakeOrderService(stockService.Object,paymentGateway.Object);// ^^^^^// We add a new MakeOrderService methodvarorder=newOrder();orderService.PlaceOrder(order);paymentGateway.Verify(t=>t.ProcessPayment(order));}privateOrderServiceMakeOrderService(IStockServicestockService,IPaymentGatewaypaymentGateway)// ^^^^^// Notice we only pass the fakes we need{vardeliveryService=newMock<IDeliveryService>();varorderRepository=newMock<IOrderRepository>();varservice=newOrderService(paymentGateway,stockService,deliveryService.Object,orderRepository.Object);returnservice;}}
With the MakeOrderService() method, we only deal with the mocks we care about in our test: the ones for IStockService and IPaymentService.
Builder methods are fine. But, we can use a special builder to create testable services with all its collaborators replaced by fakes or test doubles. This way, we don’t need to create builder methods for every combination of services we need inside our tests.
Let me introduce you to TypeBuilder. This is a helper class I’ve been using in one of my client’s projects to create services inside our unit tests.
This TypeBuilder class uses reflection to find all the parameters in the constructor of the service to build. And, it uses Moq to build fakes for each parameter.
TypeBuilder expects a single constructor. But, we can easily extend it to pick the one with more parameters.
Let’s rewrite our sample test to use the TypeBuilder class.
usingMicrosoft.VisualStudio.TestTools.UnitTesting;usingMoq;namespaceWithTypeBuilder;[TestClass]publicclassOrderServiceTestsTypeBuilder{[TestMethod]publicvoidPlaceOrder_ItemInStock_CallsPaymentGateway(){// 1. Create a buildervartypeBuilder=newTypeBuilder<OrderService>();// ^^^^^// 2. Configure a IStockService fake with MoqtypeBuilder.WithMock<IStockService>(mock=>// ^^^^^{mock.Setup(t=>t.IsStockAvailable(It.IsAny<Order>())).Returns(true);});// 3. Build an OrderService instancevarservice=typeBuilder.Build();// ^^^^^varorder=newOrder();service.PlaceOrder(order);// Retrieve a fake from the buildertypeBuilder.Mock<IPaymentGateway>()// ^^^^.Verify(t=>t.ProcessPayment(It.IsAny<Order>()));}}
This is what happened. First, we create a builder with var typeBuilder = new TypeBuilder<OrderService>();.
Then, to register a custom fake, we used the method WithMock<T>(). And inside it, we configured the behavior of the fake.
In our case, we created a fake StockService that returns true for any order. We did that in these lines:
After that, with the method Build() we got an instance of the OrderService class with fakes for all its parameters. But, the fake for IStockService has the behavior we added in the previous step.
Finally, in the Assert part, we retrieved a fake from the builder with Mock<T>(). We used it to verify if the payment gateway was called or not. We did this here:
This TypeBuilder class comes in handy to avoid creating builders manually for every service in our unit tests.
Did you notice in our example that we didn’t have to write fakes for all collaborators? We only did it for the IStockService. The TypeBuilder took care of the other fakes.
3. Auto-mocking with AutoFixture
If you prefer a more battle-tested solution, let’s replace our TypeBuilder with AutoFixture.
What AutoFixture does
From its docs, AutoFixture“is a tool designed to make Test-Driven Development more productive and unit tests more refactoring-safe”.
AutoFixture creates test data for us. It helps us to simplify the Arrange parts of our tests.
To start using AutoFixture, let’s install its NuGet package AutoFixture.
For example, we can create orders inside our tests with:
AutoFixture will initialize all properties of an object to random values. Optionally, we can hardcode our own values if we want to.
AutoMoq
AutoFixture has integrations with mocking libraries like Moq to create services with all its parameters replaced by fakes. To use these integrations, let’s install the NuGet package AutoFixture.AutoMoq.
Let’s rewrite our sample test, this time to use AutoFixture with AutoMoq. It will look like this:
usingAutoFixture;usingAutoFixture.AutoMoq;usingMicrosoft.VisualStudio.TestTools.UnitTesting;usingMoq;namespaceWithAutoFixture;[TestClass]publicclassOrderServiceTestsAutoFixture{// 1. Create a field for AutoFixtureprivatereadonlyIFixtureFixture=newFixture().Customize(newAutoMoqCustomization());// ^^^^^[TestMethod]publicvoidPlaceOrder_ItemInStock_CallsPaymentGateway(){varstockedService=Fixture.Freeze<Mock<IStockService>>();// ^^^^^// 2. Use Freeze to create a custom fakestockedService.Setup(t=>t.IsStockAvailable(It.IsAny<Order>())).Returns(true);varpaymentGateway=Fixture.Freeze<Mock<IPaymentGateway>>();varservice=Fixture.Create<OrderService>();// ^^^^^// 3. Use Create to grab an auto-mocked instancevarorder=newOrder();service.PlaceOrder(order);paymentGateway.Verify(t=>t.ProcessPayment(order));}}
Notice this time, we used a field in our test to hold a reference to AutoFixture Fixture class. Also, we needed to add the AutoMoqCustomization behavior to make AutoFixture a type builder.
To retrieve a fake reference, we used the Freeze<T>() method. We used these references to plug the custom behavior for the IStockService fake and to verify the IPaymentGateway fake.
Voilà! That’s how we can use a TypeBuilder helper class and AutoFixture to simplify the Arrange parts of our tests. If you prefer a simple solution, use the TypeBuilder class. But, if you don’t mind adding an external reference to your tests, use AutoFixture. Maybe, you can use it to create test data too.
Ready to upgrade your unit testing skills? Write readable and maintainable unit test with my course Mastering C# Unit Testing with Real-world Examples on Udemy. Learn unit testing best practices while refactoring real unit tests from my past projects. No tests for a Calculator class.
Last time, we covered what fakes are in unit testing and the types of fakes. We wrote two tests for an OrderService to show the difference between stubs and mocks.
In case you missed it, fakes are like test “simulators.” They replace external dependencies with testable components. Stubs and mocks are two types of fakes. Stubs are “simulators” that provide values or exceptions. And mocks are “simulators” that record method calls.
Before we start with the tips, let’s bring back the OrderService class from our last post.
In our last post, we chose certain names for our fakes like AlwaysAvailableStockService and FixedDateClock. Let’s see why those names and what to do and not to do when working with fakes.
TL;DR
Don’t assert on stubs
Keep one mock per test
Avoid logic inside your fakes
Make tests set their own values for fakes
Name your fakes properly
1. Don’t assert on stubs
Let’s remember that stubs are there to provide values indirectly to our code under test. We make fakes return a value or throw an exception.
Don’t write assertions for stubs. We don’t need them. Let’s assert on the result of our tests or use mocks.
Please, don’t do this.
[TestClass]publicclassOrderServiceTests{[TestMethod]publicvoidPlaceOrder_ItemInStock_CallsPaymentGateway(){varpaymentGateway=newFakePaymentGateway();varstockService=newAlwaysAvailableStockService();varservice=newOrderService(paymentGateway,stockService);varorder=newOrder();service.PlaceOrder(order);Assert.IsTrue(paymentGateway.WasCalled);// We don't need this assertionAssert.IsTrue(stockService.IsStockAvailable(order));// ^^^^^}}
If we write assertions for our stubs, we’re testing the mocking library, not our code.
2. Keep one mock per test
In the same spirit of keeping a single assertion per test, let’s keep one mock per test. Let’s have small and well-named tests.
Let’s say that in our OrderService, we need to log every request we made to charge a credit card and we add an ILogger<AccountService> to our service.
Please, don’t write tests with more than one mock. Like this one,
[TestClass]publicclassOrderServiceTests{[TestMethod]publicvoidPlaceOrder_ItemInStock_CallsPaymentGatewayAndLog(){varlogger=newFakeLogger();varpaymentGateway=newFakePaymentGateway();varstockService=newAlwaysAvailableStockService();varservice=newOrderService(logger,paymentGateway,stockService);varorder=newOrder();service.PlaceOrder(order);Assert.IsTrue(paymentGateway.WasCalled);Assert.IsTrue(logger.WasCalled);// ^^^^^// Let's keep one mock per test}}
Don’t use multiple mocks per test. Let’s write separate tests, instead.
For example, let’s not add flags to our stubs to return one value or another. Let’s write separate fakes, instead.
Let’s test the OrderService with and without stock. As a counterexample, let’s use a single FakeStockService with a flag to signal the two scenarios.
[TestClass]publicclassOrderServiceTests{[TestMethod]publicvoidPlaceOrder_ItemInStock_CallsPaymentGateway(){varpaymentGateway=newFakePaymentGateway();// Make the stock service have stockvarstockService=newFakeStockService{ItemInStock=true// ^^^^^};varservice=newOrderService(paymentGateway,stockService);varorder=newOrder();service.PlaceOrder(order);Assert.IsTrue(paymentGateway.WasCalled);}[TestMethod]publicvoidPlaceOrder_ItemOutOfStock_ThrowsException(){varpaymentGateway=newFakePaymentGateway();// Make the stock service have NO stockvarstockService=newFakeStockService{ItemInStock=false// ^^^^^};varservice=newOrderService(paymentGateway,stockService);varorder=newOrder();Assert.ThrowsException<OutOfStockException>(()=>service.PlaceOrder(order));}}
Here our fake service uses a bool, but it could start getting more complex if we need to support more test scenarios.
Let’s not use a single fake for both scenarios. Instead, let’s write two separate fakes and make each test use a different one. Let’s name these two fakes: ItemInStockStockService and ItemOutOfStockStockService. Inside them, we always return true and false, respectively.
[TestClass]publicclassOrderServiceTests{[TestMethod]publicvoidPlaceOrder_ItemInStock_CallsPaymentGateway(){varpaymentGateway=newFakePaymentGateway();// One fake for the "in stock" scenariovarstockService=newItemInStockStockService();// ^^^^^varservice=newOrderService(paymentGateway,stockService);varorder=newOrder();service.PlaceOrder(order);Assert.IsTrue(paymentGateway.WasCalled);}[TestMethod]publicvoidPlaceOrder_ItemOutOfStock_ThrowsException(){varpaymentGateway=newFakePaymentGateway();// Another fake for the "out of stock" scenariovarstockService=newItemOutOfStockStockService();// ^^^^^varservice=newOrderService(paymentGateway,stockService);varorder=newOrder();Assert.ThrowsException<OutOfStockException>(()=>service.PlaceOrder(order));}}
Don’t worry about creating lots of fakes. Fakes are cheap. Any decent IDE can create a class implementing an interface or an abstract class with a few clicks or a single keyboard shortcut.
4. Make tests set their own values for fakes
Avoid magic values in your stubs. Let’s make tests pass their own values instead of having hard-coded values in stubs.
Let’s say that StockService returns the units available instead of a simple true or false. Check this test,
It makes more sense! There’s only 1 unit available and we’re placing an order for 2 items. Let’s make tests fake their own values.
5. Name your fakes properly
Again for our last tip, let’s talk about names. Naming is hard!
Name stubs to indicate the value they return or the exception they throw.
We named our fake stock provider AlwaysAvailableStockService to show it always returns stock available. It obvious from its name what is the return value.
When we needed two stock providers to test the OrderService without stock, we named our fakes: ItemInStockStockService and ItemOutOfStockStockService.
Also, do you remember why we named our fake FixedDateClock? No? You can tell it by its name. It returns a fixed date, the DateTime you pass to it.
Voilà! Those are five tips to write better stubs and mocks. Remember, write dumb fakes. Don’t put too much logic in them. Let the tests fake their own values.
Do you know what are fakes? Are stubs and mocks the same thing? Do you know if you need any of them? Once I made the exact same questions. Let’s see what are fakes in unit testing.
In unit testing, fakes or test doubles are classes or components that replace external dependencies. Fakes simulate successful or failed scenarios to test the logic around the real dependencies they replace.
The best analogy to understand fakes are flight simulators. With a flight simulator, teachers create flight and environment conditions to train and test their pilot students in controlled scenarios.
Fakes are like flight simulators. Fakes return values, throw exceptions or record method calls to test the code around it. They create the conditions to test our code in controlled scenarios.
Let’s move to an example. In our last post when we wrote tests that use DateTime.Now, we slightly covered the concept of fakes. In that post, we wrote a validator for credit cards. It looks something like this:
publicclassCreditCardValidator:AbstractValidator<CreditCard>{publicCreditCardValidator(ISystemClocksystemClock){// Rest of code here...varnow=systemClock.Now;}}publicinterfaceISystemClock{System.DateTimeNow{get;}}publicclassSystemClock:ISystemClock{publicDateTimeNow=>DateTime.Now;}
We created a ISystemClock interface with a Now property to replace DateTime.Now inside our validator. Then, in the unit tests, instead of using SystemClock with the real date and time, we wrote a FixedDateClock class to always return the same date and time.
This is one of the tests where wrote that uses the FixedDateClock class.
Well, that FixedDateClock is a fake. It replaces the SystemClock holding the real date and time with a testable alternative. With that fake in place, we make our tests use any date and time we want instead of the real date and time.
To be more precise, the FixedDateClock is a stub. But, let’s find out about stubs and mocks.
What’s the difference between Mocks and Stubs?
Now that we know what fakes are, let’s see two types of fakes: mocks and stubs. This is the difference between them.
Both mocks and stubs are fakes or test doubles. Stubs provide values or exceptions to the code under test and mocks are used to assert that a method was called with the right parameters.
OrderService example
To better understand the difference between mocks and stubs, let’s use another example. Let’s process online orders with an OrderService class.
This OrderService checks if an item has stock available to then charge a credit card. Imagine it uses an online payment processing software and a microservice to find the stock of an item. We use two interfaces, IPaymentGateway and IStockService, to represent the two dependencies. Something like this,
The AlwaysAvailableStockService fake is there to provide a value for our test. It’s a stub. And, the FakePaymentGateway is used to assert that the OrderService called the method to charge a credit card. It’s a mock. Actually, we could call it MockPaymentGateway.
Again, stubs provides values and mocks are used to assert.
Let’s use fakes in our unit tests when we depend on external systems we don’t control. For example, third-party APIs and message queues. Let’s assert the right call were made or the right messages were sent.
Other types of fakes: dummies, stubs, spies and mocks
We learned about mocks and stubs. But, there are more types of fakes or doubles.
The book xUnit Patterns presents a broader category of fakes. It uses: dummies, stubs, spies and mocks. Let’s quickly go through them.
Dummies are used to respect the signature of methods and classes under test. A dummy is never called inside the code under test. A null value or a null object, like NullLogger, in a class constructor are dummies when we’re testing one of the class methods that doesn’t use that parameter.
Stubs feed our code under test with indirect input values. We use stubs when the real dependencies aren’t available in the test environment or when using one will have side effects. Like charging a credit card. For “xUnit Patterns” stubs are exactly the same as what we described earlier.
Spies are observation points added to the code under test. We use spies to check if the code under test called another component or not, and the parameters it used. According to “xUnit Patterns”, mocks we wrote earlier are actually spies.
Mocks are testable replacements that check if they were used correctly. We use mocks when we know in advanced the parameters the code under test will use. With mocks, we set the expected parameters to be used before calling the code under test. Then, we use a verification method in the mock itself to check if the mock was called with those exact same parameters.
Let’s not get confused with all these terms. Let’s stick to the types of fakes presented in the book The Art of Unit Testing. In there, there are only two types of fakes or test doubles: stubs and mocks. Everything else is a fake. Easier!
Parting thoughts
Voilà! That’s what fakes are in unit testing. Remember, stubs provide values for our tests and mocks assert that calls were made. That’s the difference between them.
Often, we use the terms fake, stubs and mocks interchangeably. And sometimes we use the term “mocking” to mean the replacement of external components with testable equivalents. But, we have seen there’s a distinction between all these terms.
And don’t miss the rest of my Unit Testing 101 series where I cover more subjects like this one.
Ready to upgrade your unit testing skills? Write readable and maintainable unit test with my course Mastering C# Unit Testing with Real-world Examples on Udemy. Learn unit testing best practices while refactoring real unit tests from my past projects. No tests for a Calculator class.
In our last post about using builders to create test data, we wrote a validator for expired credit cards. We used DateTime.Now all over the place. Let’s see how to write better unit tests that use the current time.
To write tests that use DateTime.Now, create a wrapper for DateTime.Now and use a fake or test double with a fixed date. As an alternative, create a setter or an optional constructor to pass a reference date.
Let’s continue where we left off. Last time, we wrote two tests to check if a credit card was expired using the Builder pattern. These are the tests we wrote at that time.
These two tests rely on the current date and time. Every time we run tests that rely on the current date and time, we will have a different date and time. It means we will have different test values and tests each time we run these tests.
We want our tests to be deterministic. We learned that from Unit Testing 101. Using DateTime.Now in our tests isn’t a good idea.
What are seams?
To replace the DateTime.Now in our tests, we need seams.
A seam is a place to introduce testable behavior in our code under test. Two techniques to introduce seams are interfaces to declare dependencies in the constructor of a service and optional setter methods to plug in testable values.
Let’s see these two techniques to replace the DateTime.Now in our tests.
1. Use a fake or test double to replace DateTime.Now
To make our tests more reliable, let’s create an abstraction for the current time and make our validator depend on it. Later, we can pass a fake or test double with a hardcoded date in our tests.
Let’s create an ISystemClock interface and a default implementation. The ISystemClock will have a Now property for the current date and time.
Our CreditCardValidator will receive in its constructor a reference to ISystemClock. Then, instead of using DateTime.Now in our validator, it will use the Now property from the clock.
publicclassCreditCardValidator:AbstractValidator<CreditCard>{publicCreditCardValidator(ISystemClocksystemClock){varnow=systemClock.Now;// Beep, beep, boop// Rest of the code here...}}
Next, let’s create a testable clock and use it in our tests.
Notice we named our fake clock FixedDateClock to show it returns the DateTime we pass to it.
Our tests with the testable clock implementation will look like this,
[TestClass]publicclassCreditCardValidationTests{[TestMethod]publicvoidCreditCard_ExpiredYear_ReturnsInvalid(){varwhen=newDateTime(2021,01,01);varclock=newFixedDateClock(when);// This time we're passing a fake clock implementationvarvalidator=newCreditCardValidator(clock);// ^^^^^varrequest=newCreditCardBuilder().WithExpirationYear(when.AddYears(-1).Year)// ^^^^.Build();varresult=validator.TestValidate(request);result.ShouldHaveAnyValidationError();}[TestMethod]publicvoidCreditCard_ExpiredMonth_ReturnsInvalid(){varwhen=newDateTime(2021,01,01);varclock=newFixedDateClock(when);varvalidator=newCreditCardValidator(clock);// ^^^^^varrequest=newCreditCardBuilder().WithExpirationMonth(when.AddMonths(-1).Month)// ^^^^.Build();varresult=validator.TestValidate(request);result.ShouldHaveAnyValidationError();}}
With a testable clock in our tests, we replaced all the references to DateTime.Now with a fixed date in the past.
UPDATE (June 2024): .NET 8.0 introduced TimeProvider, a new abstraction to use and test time. With this new built-in abstraction, we don’t need to roll our own ISystemClock.
Create constants for common test values
To make things cleaner, let’s refactor our tests. Let’s use a builder method and read-only fields for the fixed dates.
That’s how we can abstract the current date and time with an interface.
2. Use a parameter in a constructor
Now, let’s see the second alternative. To replace the interface from our first example, in the constructor we can pass a delegate returning a reference date. Like this:
publicclassCreditCardValidator:AbstractValidator<CreditCard>{publicCreditCardValidator(Func<DateTime>nowSelector)// ^^^^^{varnow=nowSelector();// Beep, beep, boop// Rest of the code here...}}
Or, even simpler we can pass a plain DateTime parameter. Like this:
publicclassCreditCardValidator:AbstractValidator<CreditCard>{publicCreditCardValidator(DateTimenow)// ^^^^^{// Beep, beep, boop// Rest of the code here...}}
Let’s stick to a simple parameter and update our tests.
Another variation on this theme is to create a setter inside the CreditCardValidator to pass an optional date. Inside the validator, we should check if the optional date is present to use DateTime.Now or not. Something like this,
And don’t miss the rest of my Unit Testing 101 series where I cover more subjects like this one.
Ready to upgrade your unit testing skills? Write readable and maintainable unit test with my course Mastering C# Unit Testing with Real-world Examples on Udemy. Learn unit testing best practices while refactoring real unit tests from my past projects. No tests for a Calculator class.
Last time, we learned how to write good unit tests by reducing noise inside our tests. We used a factory method to simplify complex setup scenarios in our tests. Let’s use the Builder pattern to create test data for our unit tests.
With the Builder pattern, an object creates another object. A builder has methods to change the state of an object and a Build() method to return that object ready to use. Often, the Builder pattern is used to create input data inside unit tests.
Tests without Builders
To see the Builder pattern in action, let’s validate credit cards. We will use the FluentValidation library to create a validator class. We want to check if a credit card is expired or not. We can write these tests,
In these tests, we used the TestValidate() and ShouldHaveAnyValidationError() helper methods from FluentValidation to write more readable assertions.
In each test, we created a CreditCard object and modified one single property for the given scenario. We had duplication and magic values when initializing the CreditCard object.
In our tests, we should give enough details to our readers, but not too many details to make our tests noisy. We should keep the details at the right level.
In our previous tests, we only cared about a credit card expiration year and month. We can abstract the creation of the CreditCard objects to avoid repetition.
One alternative to abstract the creation of CreditCard objects is to use an object mother.
An object mother is a factory method or property holding a ready-to-use input object. Each test changes the properties of an object mother to match the scenario under test.
For our example, let’s create a CreditCard property with valid defaults and tweak it inside each test.
Our tests with an object mother for credit cards will look like this,
[TestClass]publicclassCreditCardValidationTests{[TestMethod]publicvoidCreditCard_ExpiredYear_ReturnsInvalid(){varvalidator=newCreditCardValidator();varrequest=CreditCard;// ^^^^^// Instead of creating a new card object each time,// we rely on this new CreditCard propertyrequest.ExpirationYear=DateTime.Now.AddYears(-1).Year;varresult=validator.TestValidate(request);result.ShouldHaveAnyValidationError();}[TestMethod]publicvoidCreditCard_ExpiredMonth_ReturnsInvalid(){varvalidator=newCreditCardValidator();varrequest=CreditCard;// ^^^^^request.ExpirationMonth=DateTime.Now.AddMonths(-1).Month;varresult=validator.TestValidate(request);result.ShouldHaveAnyValidationError();}// We have this new property to hold a valid credit cardprivateCreditCardCreditCard// ^^^^^=>newCreditCard{CardNumber="4242424242424242",ExpirationYear=DateTime.Now.Year,ExpirationMonth=DateTime.Now.Month,Cvv=123};}
Notice the CreditCard property in our test class and how we updated its values from test to test.
Object mothers are fine if we don’t have lots of variations of the object being constructed. But, since this is a post on Builder pattern, let’s create a Builder for credit cards.
A Builder is a regular class with two types of methods: a Build() method and one or more chainable WithX() methods.
The Build() method returns the object the builder builds.
The WithX() methods update one or more properties of the object being built. In this name, the X refers to the property the method changes.
These WithX() methods return a reference to the builder itself. This way, we can chain many WithX() methods one after the other. One for each property we want to change.
For our example, let’s create a CreditCardBuilder with three methods: WithExpirationYear(), WithExpirationMonth(), and Build().
publicclassCreditCardBuilder{privatestring_cardNumber;privateint_expirationYear;privateint_expirationMonth;privateint_cvv;publicCreditCardBuilderWithExpirationYear(intyear){_expirationYear=year;returnthis;}publicCreditCardBuilderWithExpirationMonth(intmonth){_expirationMonth=month;returnthis;}// Other WithX() methods...publicCreditCardBuild(){returnnewCreditCard{CardNumber=_cardNumber,ExpirationYear=_expirationYear,ExpirationMonth=_expirationMonth,Cvv=_cvv};}}
In our builder, we have one field for each property of the CreditCard class. We can create as many WithX() methods as properties we need to use in our tests.
How to initialize values inside Builders?
To initialize the properties of the object being built, we can create a WithTestValues() method to pass safe defaults or initialize all the fields on the builder directly.
Let’s stick to the safe defaults out-the-box for our example.
publicclassCreditCardBuilder{privatestring_cardNumber="4242424242424242";// ^^^^^privateint_expirationYear=DateTime.Now.Year;// ^^^^^privateint_expirationMonth=DateTime.Now.Month;// ^^^^^privateint_cvv=123;// ^^^// All WithX() methods...publicCreditCardBuild(){returnnewCreditCard{CardNumber=_cardNumber,ExpirationYear=_expirationYear,ExpirationMonth=_expirationMonth,Cvv=_cvv};}}
Now that we have a CreditCardBuilder, let’s update our two sample tests to use it. Notice that when we use the Builder pattern, the last method in the chain of calls is always the Build() method.
[TestClass]publicclassCreditCardValidationTests{[TestMethod]publicvoidCreditCard_ExpiredYear_ReturnsInvalid(){varvalidator=newCreditCardValidator();// Now, instead of creating cards with the new keyword// or using object mothers, we use a buildervarcreditCard=newCreditCardBuilder()// ^^^^^.WithExpirationYear(DateTime.Now.AddYears(-1).Year).Build();varresult=validator.TestValidate(creditCard);result.ShouldHaveAnyValidationError();}[TestMethod]publicvoidCreditCard_ExpiredMonth_ReturnsInvalid(){varvalidator=newCreditCardValidator();varcreditCard=newCreditCardBuilder()// ^^^^^.WithExpirationMonth(DateTime.Now.AddMonths(-1).Month).Build();varresult=validator.TestValidate(creditCard);result.ShouldHaveAnyValidationError();}}
How to compose Builders?
With the Builder pattern, we can compose many builders to make our tests easier to read.
To show composition with builders, let’s book a room online. If we use an expired credit card when booking a room, our code will throw an exception. Let’s write a test for that.
Notice this time, we have a BookingRequestBuilder to create booking requests. This builder has two methods: WithGuest() and WithCreditCard(). Instead of creating credit cards directly, we used the CreditCardBuilder again. We created a new ExpiredCreditCard() method to build expired credit cards.
We can simplify our WithCreditCard() method even further to receive a credit card builder, not a credit card object. Like this.
[TestClass]publicclassBookRoomTests{[TestMethod]publicvoidBookRoom_ExpiredCreditCard_ThrowsException(){varservice=newBookingService();// Notice WithCreditCard() receives a builder this timevarrequest=newBookingRequestBuilder().WithGuest("John Doe").WithCreditCard(newCreditCardBuilder().ExpiredCreditCard())// ^^^^^// No extra .Build() here.Build();Assert.ThrowsException<InvalidCreditCardException>(()=>service.BookRoom(request));}}
Voilà! That’s how we can use the Builder pattern to create test data for our unit tests. I hope you have more readable tests using the Builder pattern after reading this post. Remember, in your tests, you should give enough details to your readers, but not too many to make your tests noisy.
Ready to upgrade your unit testing skills? Write readable and maintainable unit test with my course Mastering C# Unit Testing with Real-world Examples on Udemy. Learn unit testing best practices while refactoring real unit tests from my past projects. No tests for a Calculator class.
