Clean Swift TDD Part 3 – Worker

In part 1 and part 2, you tested the ListOrdersViewController and ListOrdersInteractor, respectively. But we left it kind of hanging because we mocked out the OrdersWorker.

In this post, you’ll test the OrdersWorker to make sure it returns the correct orders.

But first, let’s abstract away the actual details of fetching orders from a data store. You’ll develop the following data stores in the process:

• Memory store
• Core Data store
• API store

The OrdersWorker can use any of these data stores. It is agnostic to the type of data store you choose to use.

Let the data stores do the heavy lifting

In a production app, orders can be stored in Core Data or over the network. However, for development and running tests as fast as possible, you don’t want to fetch orders from Core Data or the network. Instead, you want to create a memory store. Memory is the fastest storage there is!

Let’s first design the OrdersWorker with a common API such that swapping data stores becomes trivial.

In OrdersWorker.swift:

• Add an OrdersStoreProtocol and declare the fetchOrders() method.
• Add an ordersStore variable of type OrdersStoreProtocol to the OrdersWorker class.
• Add an initializer to with an ordersStore as an argument.

Your OrdersWorker.swift file should now look like:

Next, create these three data stores, and make them conform to the OrdersStoreProtocol you just defined. Just add an empty fetchOrders() method for now.

Create a new OrdersMemStore.swift file:

Create a new OrdersCoreDataStore.swift file:

Create a new OrdersAPI.swift file:

Later, it’ll be easy to swap between these three data stores, as follows:

This technique of passing a different object that conforms to the same protocol as required by the OrdersWorker’s initializer (or constructor) is called constructor dependency injection.

The details of how to actually fetch orders in each data store is specific and internal to the implementation of the data stores themselves. The OrdersWorker is just a consumer of the OrdersStoreProtocol API.

Some housekeeping before TDD

You just changed the way an OrdersWorker object is instantiated. So, let’s go back to fix the ListOrdersInteractor to make ordersWorker use the OrdersMemStore for testing purpose:

And ListOrdersInteractorTests:

Now your project should compile again.

Isolate the dependencies

As always, it is very useful to first identify and isolate any dependency. You are testing the OrdersWorker and its ordersStore variable points to an external data store. Whether it is in memory, Core Data, or over the network, it is a dependency. Let’s mock it out.

To simulate the asynchronous (background and non-blocking) nature of fetching orders, let’s use GCD to postpone invoking the completionHandler by 1 second.

The fetchOrders() method returns immediately. After 1 second, the completionHandler will fire in the main queue. We’ll just create a couple orders and return them as an array.

This OrdersMemStoreSpy goes inside the OrdersWorkerTests class, which you’ll see next.

Write the test first

In the last post, you mocked out the OrdersWorker to test the ListOrdersInteractor. Now it’s time to TDD the OrdersWorker to make it fetch some real orders from the data store.

In the setupOrdersWorker() method, you set up the subject under test, an instance of OrdersWorker, to use the OrdersMemStoreSpy you wrote at the beginning of this post.

In the Given, you first get a reference to this spy so you can inspect it later when you write your assertions.

In the When, you’ll use XCTest’s asynchronous testing support. First, make a call to the expectationWithDescription() method. Then, invoke the fetchOrders() method. Inside the block, call the fulfill() method to fulfill the expectation.

In the Then, as usual, you verify the fetchOrders() method was called. You also invoke waitForExpectationsWithTimeout() to wait 1.1 seconds (just a bit longer than the dispatch_after in OrdersMemStoreSpy) for the expectation to be fulfilled. If the expectation is fulfilled, it means the completion handler is properly executed. Exactly what you want.

Implement the logic

The test is currently failing because the OrdersWorker is calling the completion handler immediately and return an empty array of orders. No orders!

Let’s make it pass.

Modify the OrdersWorker’s fetchOrders() method to use the new ordersStore variable to fetch orders from the data store as follows:

Instead of calling the completionHandler immediately and return an empty array of orders, you invoke the fetchOrders() method on ordersStore. When fetchOrders() completes, you call the completionHandler inside the fetchOrders() method’s block.

Also, modify the completionHandler call to return the orders result as returned by the ordersStore.

Run the test now and it should pass. All the code and test for this TDD example can be found on GitHub.

Recap

We broke out of the VIP cycle a bit and steer right into the worker. We then use TDD to drive the development of the OrdersWorker.

• First, you defined a simple API contract – the OrdersStoreProtocol with a single fetchOrders() method.
• Next, you created the three data stores: (1) OrdersMemStore, (2) OrdersCoreDataStore, and (3) OrdersAPI. They all conform to the OrdersStoreProtocol.
• The OrdersWorker is then free to pick one of these three data stores to use with the help of constructor dependency injection.
• To isolate the OrdersWorker’s dependency on ordersStore, you created the OrdersMemStoreSpy. You use GCD to simulate returning orders asynchronously.
• You wrote the testFetchOrdersShouldReturnListOfOrders() test to verify the data store’s fetchOrders() method is invoked.
• You also use XCTest’s asynchronous testing support to create and wait for an expectation to be fulfilled. When it’s fulfilled, you know the data store’s fetchOrders() method has returned some orders.

In the next post, we’ll get back on the VIP cycle to finish off by testing the presenter using TDD.