Unit Test on Andrew Bancroft

An (Almost) TDD Workflow in Swift

Wed, 11 Mar 2015 01:46:59 +0000

There are times when it feels paralyzing to write tests first before any production code is written. Even with good requirements documentation, I often find myself asking, “How am I supposed to write a test to verify x about some thing that doesn’t exist in actual code yet?” It can be crippling.

The following is a workflow that’s helped me grow in my test-first development skills. When I find myself staring at the screen, paralyzed because I’m “not supposed to write actual production code until the test is written”, I often turn to the workflow that I’m about to describe to help me break through to being productive. With practice and experience, I find myself needing this strategy less and less, but I’ve found it helpful to use this (almost) TDD workflow as a gateway into full test-first development.

Set up side-by-side view: Test on left | Code on right

My starting place is to always have a test file open on the left, and the actual production code file that I want to write tests for on the right. This does a couple of things for me:

It helps me avoid a lot of switching back and forth between tests and production code.
It helps me keep tests at the forefront of my mind. Without seeing them in front of me, I could more easily forget about them. Having the split IDE keeps me conscious of the need to prioritize testing.

I recently wrote about a technique to seed a Core Data database, and with that post, I included a project called “Zootastic” – a contrived app that modeled the storage and display of Zoos (along with Animals and their Classifications). I created a class called DataHelper which had several seed() methods. For the purposes of having an example before us, suppose that I wanted to test DataHelper. My screen might look something like this, with my tests on the left, and my DataHelper class on the right:

Write the actual production code

What I want is to insert 3 Zoo objects into the Core Data data store. But without the actual code before me, it’s hard to imagine what the test(s) for that code might look like.

When I get stuck in this way, I’ll go ahead and write the actual production code:

One important thing to remember is that you don’t want to write a ton of code in this step… just enough to spark your brain into figuring out what kinds of tests you can write. Write small increments of code. The more you write, the harder it will be to ensure you’ve covered the code and the various edge cases that may exist. Your goal is not to write the app. Your goal is to write a function, or a part of the function – just enough to get you going with tests.

Write a test that will exercise the code

Having some real code with real class names and real function names usually helps me see what I need to do in terms of testing.

In the example I have going, I’d like my seedZoos() function to insert 3 Zoo objects into my CoreData data store.

At this point, it’s pretty easy for me to think of the name of my first test. How about, testSeedZoosInserts3ZooObjectsIntoDataStore():

Comment out the production code so that the test will fail

Running the tests right now would produce a passing test. “Great!”, you say – but here’s my issue with simply running the test, seeing it pass, and moving on without ever having seen it fail:

There are many ways to produce passing tests without actually verifying the results of executing the app’s code.

I could write a test with no assert. That’d be silly, but forgetting that at the end would produce a green test – and it’s easier to do than you think as you get rolling with these things. Expecting the first time you run the test to produce a failing test would alert you if you ran it the first time and saw a passing one.
I could write a test that asserts the wrong thing and produces a false positive. Again, expecting “fail” at first would alert me if I saw “pass” at first.
Suppose I copied and pasted a test and intended to replace the implementation to test my new code. But I get distracted between when I pasted it and when I ran it for the first time. If I ran it, saw “pass” and moved on, the test wouldn’t be doing its job – it’d be testing something that I already tested, and not these new lines of code I just produced!

The point is this: There are too many ways to write a test that doesn’t truly test your code. Suffice it to say, you should always make the test fail so that you know it’s wired up to the right production code. Thus, this crucial step: comment out the production code. It’ll ensure you get a failing test on the first run (if you’re truly testing the right thing).

Run the test and verify that it fails

With the production code I just wrote commented out, I run the test. My expectation at this point is that it will fail, because the seedZoos() function does not currently insert any Zoo objects into the data store.

If the test doesn’t fail, something is wrong. Check the basics: Did you include an assert at the end of the test? Are you exercising the right production code? Continue troubleshooting and re-running the test until it fails.

Uncomment the production code so that the test will pass

Once I’ve been able to make the test fail, I uncomment the production code.

The idea here is that once the production code is now “live”, the test that’s currently failing should pass, now that production code is performing appropriate logic to meet the test’s assertion requirements. We know that the test currently fails, so if it passes after we uncomment the production code, the only reason it could pass is because the production code is doing the right thing for that particular test’s assertion. Nothing else about our work environment changed, so nothing else except the uncommented production code could have been the cause of the passing test.

Here’s a view of the IDE in the state right before I run the test again to watch it pass:

Run the test and verify that it passes

The last step in this (almost) TDD workflow is to run the test one more time. This time it should pass:

If the test doesn’t pass, then something is wrong. Check the basics: Does the test assert the right thing? Does the production code perform correct logic that would satisfy the test’s assertion? Continue troubleshooting and revise the necessary code until you have a passing test.

Rinse and repeat

You can perform this workflow as my times as you need. This is a stepping stone, so the hope is that eventually you’ll be able to write the tests first. It takes a little practice, but using this technique has, in my experience, been a gateway to true Test Driven Development.

Swift Access Control – Implications for Unit Testing

Wed, 23 Jul 2014 04:04:43 +0000

If you find yourself with broken unit tests, failing to build with the error, “Use of unresolved identifier…”, you’re not alone!

Unit Tests and Swift Access Control

When Swift access control came into the picture, we suddenly had a little more to consider. From the Apple docs:

Swift access control has three access levels:

private entities can only be accessed from within the source file where they are defined.
internal entities can be accessed anywhere within the target where they are defined.
public entities can be accessed from anywhere within the target and from any other context
that imports the current target’s module.

By default, most entities in a source file have internal access.
So given the following…

Out of the box, your unit tests are part of a separate test target
The default access control for a class is internal, (meaning that if you do not explicitly specify an access control on the class / properties / functions, they’re marked internal behind the scenes)

… we now know why the unit tests break, unless we make a few tweaks: classes marked internal are only seen within a set of specified targets and our unit tests are in a separate target that our class is not a part of by default.

Options

It seems to me that we have two options:

Change the access control on our class to public. Additionally, mark any methods we intend to test with public also.
Add the class(es) you want to be able to write unit tests for to the tests target.

Solution

I found option #2 to be the easiest to implement at first. However, it turns out that this can lead to some really obscure issues. An enlightening Twitter conversation also shed some light on the subject, and pointed to the solution of testing only publicly accessible behavior that your Types expose, rather than trying to test internal implementation. That probably deserves a blog entry of its own, but for now, I’ll leave it to say that I’d recommend not adding your .swift source files to your test target, but rather to adjust the access control modifiers of the things you want to test to public (ie, Option # 1).

How to Create Mocks and Stubs in Swift

Tue, 15 Jul 2014 05:12:16 +0000

Without 100% support for a mocking framework like OCMock, I found myself needing to get creative when building mock objects and method stubs in Swift unit tests. The great thing about testing is that you’re…well… testing things out to see if they’ll work, and I found a solution that I’m pretty happy with for now. I’m open to better ways, so leave a comment if you’ve had good results using a different design!

The process is essentially this (example to follow):

Ensure that the class that you would like to test is designed so that you can substitute your mock for the real one that’s used in your class’ implementation
Create an XCTestCase class with a test function in your unit test project
Within the function body create a nested class
Make the nested class inherit from the real object you’re trying to mock / create a method stub for
You can give the nested class a name such as Mock[ObjectName]
Configure the mock object however you need by setting its properties or overriding its function implementations with stubbed implementations – no need to override every function… only the one(s) that your class calls during the test at hand
Instantiate the class you’re testing and pass in an instance of the mock object you just nested in the test function to your class somehow (either through its initializer, by setting a property on the class, or by passing it into the method under test via parameter — however you intended to ‘inject’ the mock from step 1 is what you should do)
XCTAssert…

Let’s see those 8 steps in action for those of us who are more visually inclined.

EDIT: July 22, 2014 – I’ve added a simple Xcode Project to GitHub for those interested in seeing the setup directly in Xcode at https://github.com/andrewcbancroft/MocksAndStubs

The scenario that I’d like to use a mock class in is this: I have a CoreData application and I’d like to be able to mock the NSManagedObjectContext so that instead of making actual database fetch requests, I can just provide stubs of various sorts with the kinds of responses I’d expect from the real database calls to ensure my class will do the right thing based on predictable results. To do this I begin at step 1…

1. Ensure that the class that you would like to test is designed so that you can substitute your mock for the real one that’s used in your class’ implementation

In the example class below, I intend to provide the NSManagedObjectContext dependency through the class’ initializer which will set a property that is used by my class’ methods later on, but you could easily use some other way of performing “dependency injection”. The initializer strategy just makes it super clear in my mind what the class’ dependencies are, so that’s what I’m going to do here. Have a look:

 1import Foundation
 2import CoreData
 3
 4class MyClass {
 5    let context: NSManagedObjectContext
 6    
 7    init(managedObjectContext: NSManagedObjectContext) {
 8        self.context = managedObjectContext
 9    }
10}

Now, let’s say that my example class has a member function called databaseHasRecordsForSomeEntity that returns a Bool value of true if the resulting array of a fetch request contains objects, and a Bool value of false if the result array of a fetch request is empty. The completed class looks like this:

 1import Foundation
 2import CoreData
 3
 4class MyClass {
 5    let context: NSManagedObjectContext
 6    
 7    init(managedObjectContext: NSManagedObjectContext) {
 8        self.context = managedObjectContext
 9    }
10    
11    // If the array returned from executing a fetch request contains objects, return true; if empty, return false
12    func databaseHasRecordsForSomeEntity() -> Bool {
13        let fetchRequest = NSFetchRequest(entityName: "SomeEntity")
14        let fetchRequestResults = self.context.executeFetchRequest(fetchRequest, error: nil) // May want to do something with the error in real life...
15        return (fetchRequestResults?.count > 0)
16    }
17}

I want to test if databaseHasRecordsForSomeEntity does what I intend it to do. So…

2. Create an `XCTestCase` class with a test function in your unit test project

Just listing this for completeness

Next comes the way to make the mock. Read steps 3-5 and then look below for a code example of what the skeleton will look like.

3. Within the function body create a nested class

4. Make the nested class inherit from the real object you’re trying to mock / create a method stub for

5. You can give the nested class a name such as Mock[ObjectName]

 1import UIKit
 2import XCTest
 3import CoreData // <-- Make sure to import CoreData or you will get errors when you try to use NSManagedObjectContext
 4
 5class MyClassTests: XCTestCase {
 6
 7    override func setUp() {
 8        super.setUp()
 9        // Put setup code here. This method is called before the invocation of each test method in the class.
10    }
11    
12    override func tearDown() {
13        // Put teardown code here. This method is called after the invocation of each test method in the class.
14        super.tearDown()
15    }
16
17    // Yay for verbose test names!  :]
18    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
19        class MockNSManagedObjectContext: NSManagedObjectContext {
20            
21        }
22    }
23}

6. Configure the mock object however you need by setting its properties or overriding its function implementations with stubbed implementations – no need to override every function… only the one(s) that your class calls during the test at hand

For my example, I’m going to stub out the executeFetchRequest method so that it returns an array with one object in it. This is really the part where you have to determine what you’re testing and what you expect the stubbed results to be. Whatever you decide, the way to stub a method is simply to override it in the mock you’re implementing. Here’s how I implemented the executeFetchRequest stub for my example:

1// Yay for verbose test names!  :]
2    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
3        class MockNSManagedObjectContext: NSManagedObjectContext {
4            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
5                return ["object 1"]
6            }
7        }
8    }

We’re ready to perform the test and assert the results. Read steps 7-8 and take a look at the code example below step 8:

7. Instantiate the class you’re testing and pass in an instance of the mock object you just nested in the test function to your class somehow (either through its initializer, by setting a property on the class, or by passing it into the method under test via parameter — however you intended to ‘inject’ the mock from step 1 is what you should do)

8. XCTAssert…

From step 1, I intended to pass an NSManagedObjectContext instance to the initializer of MyClass, so that’s what I’ll do in my test. I’ll then perform the XCTAssert on the return value of my method under test:

 1// Yay for verbose test names!  :]
 2    func testDatabaseHasRecordsForSomeEntityReturnsTrueWhenFetchRequestReturnsNonEmptyArray() {
 3        class MockNSManagedObjectContext: NSManagedObjectContext {
 4            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
 5                return ["object 1"]
 6            }
 7        }
 8        
 9        // Instantiate mock
10        let mockContext = MockNSManagedObjectContext()
11        
12        // Instantiate class under test and pass it the mockContext object
13        let myClassInstance = MyClass(managedObjectContext: mockContext)
14        
15        // Call the method under test and store its return value for XCTAssert
16        let returnValue = myClassInstance.databaseHasRecordsForSomeEntity()
17        
18        XCTAssertTrue(returnValue == true, "The return value should be been true")
19    }

Running the tests at this point should produce a passing test using the mock object in place of a real NSManagedObjectContext that calls a database!

Now, if I wanted to test the “false” branch of my class’ method, I could simply create another test method following the same steps, only this time, I’d provide a new implementation for the overridden executeFetchRequest method that’s appropriate:

 1func testDatabaseHasRecordsForSomeEntityReturnsFalseWhenFetchRequestReturnsEMPTYArray() {
 2        class MockNSManagedObjectContext: NSManagedObjectContext {
 3            override func executeFetchRequest(request: NSFetchRequest, error: NSErrorPointer) -> [AnyObject]? {
 4                return [] // Provided a different stub implementation to test the "false" branch of my method under test
 5            }
 6        }
 7        
 8        // Instantiate mock
 9        let mockContext = MockNSManagedObjectContext()
10        
11        // Instantiate class under test
12        let myClassInstance = MyClass(managedObjectContext: mockContext)
13        
14        // Call the method under test and store its return value for XCTAssert
15        let returnValue = myClassInstance.databaseHasRecordsForSomeEntity()
16        
17        XCTAssertTrue(returnValue == false, "The return value should be been false")
18    }

And that’s a wrap – happy mocking and stubbing in Swift!