Unit Testing on Andrew Bancroft

Creating Trust-able Unit Tests in Swift

Wed, 04 Nov 2015 02:42:08 +0000

It may come as a surprise to you, but a green-lit passing unit test is not always a sign that all is well with our software. Our apps and their corresponding unit test suites always start off clean and basic and simple.

But they don’t stay that way for long.

Cycles of code changes and additions and re-writes take place throughout the days, weeks, and months of the application development cycle. The app’s code-base and unit tests become more complex as the end-product progresses along its asymptotic approach to completion.

Unit tests are only as good as they are trust-able. As our products navigate their way through development iterations, how can we keep a handle on the trustworthiness of our unit tests? How can we be assured that they’re testing the right thing? How can we know that changing a unit test because a fundamental requirement has changed is still accurate when it lights up green? After all, we’re writing code to test our code!

Here, I explore several categories of thought that will help you think about creating trust-able unit tests.

Test Organization

How you organize the code within a single unit test can make all the difference in understanding it when you return to it later.

Having a consistent strategy for organizing the body of a test function will save you time and effort in trying to understand what’s happening. Keeping things consistent across a team of developers will make everyone more productive as well.

Two of the most common organizational structures for unit tests are the “Arrange-Act-Assert (AAA)” and the “Given-When-Then” structures:

 1func testAppFeatureBehavior() {
 2    // Arrange
 3    let sut = SystemUnderTest()
 4    // configure properties as necessary to prepare the system for the next step
 5
 6    // Act
 7    sut.functionProducingObservableBehavior()
 8
 9    // Assert
10    XCTAssert(...expectations are met...)
11}

A similar pattern is the “Given-When-Then” structure:

 1func testAppFeatureBehavior() {
 2    // Given
 3    let sut = SystemUnderTest()
 4    // configure properties as necessary to prepare the system for the next step
 5
 6    // When
 7    sut.functionProducingObservableBehavior()
 8
 9    // Then
10    XCTAssert(...expectations are met...)
11}

They’re exactly the same structures with different descriptive comments outlining the three phases of the test.

The outline itself can help you look at the test and verify its trustworthiness as it pertains to its logical, clear order and organization.

Test Length

Another contributor to the trustworthiness of a given unit test is the number of lines of code it has.

It’s been said that a 100% guaranteed bug-free line of code is the line of code that was never written in the first place!

It makes sense that if we can keep our unit tests short and to the point, there will be a smaller chance for error than if the test body is extremely long.

Small (<20ish lines of code) tests are more-trusted than large tests.

20 lines of code is sort of arbitrary, but can help alert you to when you might need to re-look at the test and apply DRY (Don’t Repeat Yourself) principles. Large test bodies may be a sign that there’s a possible opportunity to factor out common, repeated test code.

Extracting out larger portions of code into smaller named functions may also help with the clarity of your unit test code, leading you to say with greater confidence, “I trust that this test is correct”.

Test Complexity

Unit tests should be as simple as possible. Reducing the complexity of a unit test results in clarity.

Make sure there’s a clear path through the test case.

Avoid branching logic (if-else statements) or looping constructs in your tests if at all possible. If you find the need to test two code paths of your system under test, write two tests for that, rather than applying if-else logic inside of a single unit test.

If you’re using analytics, such as cyclomatic complexity, absolutely make sure your unit tests have as low of a cyclomatic complexity as possible.

Test Semantics

Applying simple clean coding practices to your unit tests can also go a long way in terms of being able to trust your tests.

Use descriptive and meaningful phrases (DAMP) in your test names and variables. Be sure to update them as the semantics of your system under test change. This will provide a consistency and accuracy to the names of things that will lead to a greater confidence that your tests are giving you an accurate picture of the health of your system.

You might also enjoy…

Testability Tip for Swift Developers – Parameterize and Push

Fri, 04 Sep 2015 18:36:52 +0000

In a previous “Testability Tip for Swift Developers”, I discussed the principle of observability. “If it’s observable, it’s testable” was the primary conclusion of the article, and I pointed toward using the public access control modifier for parts of your app that you intend to test.

In this edition, I’d like to introduce a new principle that I try to adhere to when I’m unit testing, namely, “If it’s controllable, it’s testable”. Here’s what I mean by “controllable”…

Controllability

In Testing is to Software as Experiment is to Science, I analyzed how testing software mirrors scientific experimentation. Good scientific experiments are controllable. That is, they are set up such that everything stays as constant as possible except the thing you’re poking at.

Changing multiple things at a time in an experiment clouds the ability to verify that [tweak x] produced [y outcome]. So a scientist will do his/her best to control the environment by holding as many variables constant as possible, so that he/she can make accurate conclusions about the outcome.

The same goes for testing software. If I’m going to automate a test, I want to set up my “experiment” such that I control as much of the system as possible so that I can set up valid expectations and verify results coming from the system under test. Note that I’m using the term “system” in a very broad sense – it could be referring to an entire app, a single “object”, or a function.

Parameterize and push

So where does “parameterize and push” come into play?

Parameterizing sets us up with the ability to provide inputs into the system we’re testing. Anytime you have an input, you have the ability to supply a value of your choosing.

Serving as inputs to the system, you can view parameters as entry points for controls. They’re “controls” because we decide what those values should be before we pass them off as arguments to those parameters. So long as the system we’re testing only gets the data it uses from its inputs (its parameters), we can be guaranteed predictable, controlled outputs on the other end.

Forms of parameterization

Three forms of parameterization are common:

At the instance level through initializers
At the instance level through property setters
At the function level through function parameters

Using an initializer, or a public variable property, or by adding parameters to your functions and using only those parameters for the function’s computation and output production, you give yourself the ability to control the system in various ways that are appropriate on a test-by-test basis.

Usefulness and examples of parameterization

Setting up your instance definitions to use a set of inputs from the very start through initialization gives you the ability to provide real “production-ready” values in your app, but fake “test-customized” values for testing. Creating fake objects for testing is outside the scope of this article, but providing public initializers with parameters is a really great way to set yourself up for being able to test that particular instance.

 1// Prefer
 2public class DatabaseCommunicator {
 3    let database: Database
 4    
 5    public init (database: Database) {
 6        self.database = database
 7        // able to supply a controlled input via parameter, such as supplying a 
 8        // customized "fake" database to use for testing but still supply a "real" database in real life
 9    }
10}
11
12// over
13public class DatabaseCommunicator {
14    let database = Database()
15    // stuck with talking to a real database...
16}

Another viable option is to provide public variable properties that can be set after the instance is initialized. This is a little more round-about, but I would still call it a form of “parameterization” because the strategy still provides you with the same control point that an initializer with parameters does.

 1// prefer
 2public class DatabaseCommunicator {
 3    public var database: Database
 4    // able to supply a controlled input via property setter, such as supplying a 
 5    // customized "fake" database to use for testing but still supply a "real" database in real life
 6    public init() { self.database = Database()}
 7}
 8
 9// over
10public class DatabaseCommunicator {
11    let database = Database()
12    // stuck with talking to a real database
13}

At the function level, the usefulness of parameters is that you can supply inputs and examine outputs with ease. If you pull in data from the encapsulating instance inside the function body, say by referencing self.somePropertyValue, you’ve got a bit more setup to do to be able to accurately verify results. somePropertyValue needs to actually have a value before the function will produce accurate results. If you’d opted to simply define parameters for everything the function needs in order to produce its output, you can test that function in isolation far more easily and be guaranteed that your results are correct and accurate.

 1// prefer
 2func getNameFromDatabase(database: Database) -> String {
 3    return database.getName()
 4    // able to supply a controlled input via parameter, such as supplying a 
 5    // customized "fake" database to use for testing but still supply a "real" database in real life
 6   
 7}
 8
 9// over
10func getNameFromDatabase() -> String {
11    let database = Database()
12    // stuck with talking to a real database
13    return database.getName()
14}
15
16// and over
17func getNameFromDatabase() -> String {
18    return self.database.getName()
19    // requires additional setting of the database property on 'self'
20    // before you're able to get results from this function
21}

Parameterization or “Dependency Injection”?

Yes.

What I’m calling “parameterization” is really just “dependency injection”. But the term “dependency injection” can sound really daunting, while we’re used to working with parameters. I intend for the meaning of each term for the purpose of this article to be equivalent.

Wrapping up

Parameterizing, your instance definitions and functions provides you an immense amount of leverage when it comes to controlling your system under test. I encourage you to try this out and do your best to shift to a more parameterized approach to writing your code for improved testability. Remember, “Controllable is testable”!

You might also enjoy…

Testability Tip for Swift Developers – Public Over Private

Improvements to Unit Testing in Swift with Xcode 7

Wed, 10 Jun 2015 17:43:09 +0000

One of the most exciting things that’s come out of WWDC 2015 is the fact that unit testing in Swift has been greatly simplified. The latest announcements have actually rendered a few of my articles on the subject obsolete, once Xcode 7 is in full circulation among the Swift developer community.

If you’re using Xcode 6.x, you may still find use in a couple of my previous articles:

If you’re jumping headlong into Xcode 7 world, setting yourself up for unit testing is incredibly simple. Essentially, all internal and public Types (and members of those Types) are visible to your unit test project when you import the module using the @testable keyword in front of the import. With Xcode 7, there’s no reason to change any of the access modifiers on your Types/members to support testing.

@natashatherobot has an excellent 3-step write-up that I won’t repeat here. To summarize though, you’ll simply…

Code your Types (classes/structs/enums) using the default internal access.
Add an import statement to the file containing your XCTestCases. There’s special syntax for this now: @testable import AppName/ModuleName
Begin unit testing with access to all public and internal Types and members!

Testing is to Software as Experiment is to Science

Thu, 30 Apr 2015 04:01:24 +0000

The principle of science, the definition, almost, is the following: The test of all knowledge is experiment.

The sole test of the validity of any idea is experiment.

These quote came from Chapter 1 and Chapter 2 of the Feynman Lectures on Physics.

I’m not a physicist, but the software developer in me resonated with the connection between experimentation and validation of what we know about the world around us. Almost immediately, I related it to the world of software.

Validity is confirmed by experiments (tests)

The universe around us is an immense mystery. We have many ideas about it, but the ideas that are validated by experiment are the ones we cling to more tightly than the ones that remain in the realm of guess and theory.

How do we know that things are valid within a software application? The answer, of course, is by testing that software… experimenting with it, if you will, and observing the outcomes of those experiments.

Your software is a universe of mystery until it’s tested.

Repeated experiments (tests) are most valuable

Experiments that are conducted multiple times are significantly more valuable than a single observation made from a single experiment. Repeated experiments increase the probability that what was observed was not an accident, but was truly the result of correct procedure validating a correct hypothesis. Performing the experiments as identically as possible to one other is the key to trusting the results.

Likewise, repeated testing of software is far more valuable than testing it once and walking away. Repeated tests done identically over time provide the reassurance we need to know for sure that our software behaves as we expect as it morphs to accommodate new ideas and new needs.

Sure, we could spin up the app in a simulator and click/tap through it to see if pressing [Button X] does what its label implies it will do. But I’ve heard it said that if we have to do it more than once, it should be automated.

Testing is one of those things that needs to be done often. Pretty much any time the app’s code changes (even just a little bit!), there is warrant to check and make sure the universe as we knew it still obeys all the laws we previously discovered.

Repeated tests are just as valuable to software as repeated experiment is to science. The more we can automate them, the greater the consistency in our repeated observations of how the software behaves.

Experimentation (testing) is a creative effort

Designing the right experiment to elicit the right conditions to make that one critical observation is a creative process. Sometimes, scientists have to go to great lengths to make their observations. But they all find it worth it when their experiment yields results!

I work with some amazing scientists on a day-to-day basis. Watching them work and hearing about some of the things they have to do in order to test their ideas is so fascinating to me. For example, one of our Principal Investigators is making observations about how microgravity affects a plant’s cell walls. To do that, he had to literally launch his plant’s seeds into space! They’re aboard the International Space Station. Growing plants! In space! I’m blown away by these guys!

While we needn’t launch our code into space just to experiment with it, sometimes we have to get creative in order to make the observations we need to make from our code. Automated testing isn’t easy. Running the app and clicking a button and watching what happens with our own eyes is easy, but it’s tedious and I’m lazy!

Creating the right environment (in code) for a test to verify what it needs can take effort, but in the end, when the test yields results time after time after time, I’ve always found that it’s worth it!

Wrapping up

My hope is that seeing automated unit testing from a slightly different perspective has sparked some thoughts and ideas in your mind. How can you begin experiment with your code with automated tests? How can you begin to make repeatable observations about your code so that you know, for sure, that it works, even after you go about making changes to it as time goes along?

I’ve devoted a bit time to writing about unit testing in Swift since the language was released. I hope this article adds something unique to the collection and that it gets you motivated to validate your software universe with tests!

You might also enjoy…

Testability Tip for Swift Developers – Public Over Private

Wed, 15 Apr 2015 18:52:11 +0000

Quite often in unit testing, especially when practicing Test-Driven Development, I find myself wanting to test every single line of code. When I run up against a private function, however, I often scratch my head and ask, “How am I supposed to test this??”.

Most experienced testers will tell you, “Don’t test private implementation – only public API”.

“Okay… But how, does that private function get tested?”, I always asked.

In this article, I intend to share a testability tip catered to the Swift developer community that helps alleviate this issue with testing private functions.

Testing and observability

Developers as clients of APIs

As developers, we are “clients” of APIs on a daily basis. We interact with other developers’ frameworks and libraries through the visible, observable, Application Programming Interface that they’ve exposed to us. It’s the way they’ve designed for us to interact with their code.

Notice three words that I chose in that introductory paragraph:

Visible
Observable
Exposed

If we are going to use another developer’s library, all we have as developers is the public interface that they’ve made visible to us… It’s the only observable thing we can look at and go, “Oh! Okay, to do this, I call that function”. The only thing exposed are the functions and properties that the developer intends for us to see.

Tests as clients of APIs

Have you ever viewed your unit test suite as a “client” of your code? It is!

And just like a developer, the unit tests in your test target interacts with your app’s API through the same visible, observable, interface that you’ve exposed to them.

If you start to personify your test target and think of it in terms of “just another client of your code”, you begin to see that it really doesn’t have any more visibility of your code than another developer would if he or she were consuming it.

All of this boils down to say, if it’s observable, it’s testable. Which means, the easiest and most natural code to test is public code.

Public over private (and internal)

So should everything be public instead of private or internal? Certainly not.

Object-oriented programming strives for data-hiding and encapsulation, so there are reasons to keep some things non-public.

Additionally, there are certain Swift compiler optimizations (which lead to run-time optimizations) that can be gained when you mark things in your Type as final. Using the private access modifier allows the compiler to infer that it is final because it’s narrowly scoped to the current Type only. These are handy things to know, but as is always the case with optimization, avoid premature optimization by measuring first to decide if you really need them.

Whenever possible, I prefer public over the other access modifiers to help enable testing for my apps.

So when is “whenever possible”?

Public when part of a Type’s reason for existence

Obviously, properties and functions that are part of a Type’s core purpose can be marked public. My practice is to decide, “Is this function why this Type exists?”. If so, I mark it as public.

Note also that the Type itself needs to be marked public if it’s going to be visible to your unit tests.

 1// Instead of this (default --internal-- access)...
 2class MyClass {
 3    func myFunc() {
 4        // Performs something essential to why MyClass exists
 5    }
 6}
 7
 8// Make things public...
 9public class MyClass {
10    public func myFunc() {
11        // Performs something essential to why MyClass exists
12    }
13}

Transition many private components to new Type

Having many private properties and functions can be an indication that there needs to be a new Type created to encapsulate those components. I’ve heard developers talk about this situation as one that “screams, ‘New Type!’”.

If we extract out sets of related private properties and functions into a new Type, those pieces of code are the reason that Type exists, and thus should be marked public. Testing, then, becomes a matter of writing unit tests for the new Type and its public API!

Even if you just have a few private code blocks in the Type you’re trying to test, it can sometimes make your testing life easier to transition them to a new Type as public components.

If I’m really uncomfortable marking functions public in the Type where they currently exist, creating a new Type and marking them public there is usually the better alternative, and it immediately enables testing for that set of code.

Testing non-public code

As I mentioned in the beginning, it’s not good to just haphazardly go through your code and “public all the things!!”. After appropriately marking fundamental functions public and transitioning sets of private functions to new Types where they can happily live as part of that Type’s public API, there will likely be a few private or internal things left over.

How do these get tested?

Well, ideally, these are small, simple, helper functions that are only useful when called within the Type you’re working on.

If these functions produce observable results in the places where they’re called, you end up testing these non-public components implicitly, that is, by testing the things that are public.

During the course of testing some public function which calls another non-public function, that non-public function’s logic will be executed. If the outcome of that function’s execution affects the Type’s state, or the output of its public parent function, those are the things that you’d be able to write unit tests for, because those are the “observation points”, so to speak.

Wrapping up

The bottom line is: observable == testable. Just like another developer, the suite of unit tests in your test target interacts with your app’s API through the visible, observable, interface that you’ve exposed to them. The more observable your API components are, the more testable your code becomes. Which is why I prefer public over private whenever possible!

You might also enjoy…

Unit Testing Model Layer with Core Data and Swift

Tue, 13 Jan 2015 13:00:37 +0000

Updated on November 19, 2015 – Swift 2.0

As I approached testing my Core Data model, I have to admit I was apprehensive. How in the world was I going to write unit tests for my model layer that depended on a database. Past experience with trying to write tests with databases was painful. I feared the same would be the case with Core Data.

To my surprise, unit testing my Core Data model layer has been… well… amazing. With little effort, I’ve been able to write the unit tests I’ve wanted. The process went something like this for me:

Create an NSManagedObject subclass of the Core Data entity that I need in my unit test. (This just makes things easier from an Xcode code-completion standpoint)
Write a helper function to set up an in-memory NSManagedObjectContext. Avoiding the need to use an actual sqlite database is pretty handy. It allows for quick-running tests and easy iterations over the data model itself.
Write unit tests using the in-memory NSManagedObjectContext.

I’ve already written about creating an NSManagedObject subclass, so I will unpack steps 2 and 3 in this blog entry.

Set up an in-memory NSManagedObjectContext

A Stack Overflow question+answer sparked some thoughts. The idea and the code both came from there. The answer uses Objective-C, so my contribution is that I’ve written it in Swift. In my project, I created a new Swift file called “CoreDataHelpers.swift” in my tests target. Here’s a look at the helper function:

 1import CoreData
 2
 3func setUpInMemoryManagedObjectContext() -> NSManagedObjectContext {
 4    let managedObjectModel = NSManagedObjectModel.mergedModelFromBundles([NSBundle.mainBundle()])!
 5    
 6    let persistentStoreCoordinator = NSPersistentStoreCoordinator(managedObjectModel: managedObjectModel)
 7
 8    do {
 9        try persistentStoreCoordinator.addPersistentStoreWithType(NSInMemoryStoreType, configuration: nil, url: nil, options: nil)
10    } catch {
11        print("Adding in-memory persistent store failed")
12    }
13    
14    let managedObjectContext = NSManagedObjectContext()
15    managedObjectContext.persistentStoreCoordinator = persistentStoreCoordinator
16    
17    return managedObjectContext
18}

Observations

I’ll be honest, I’m only starting to put together the pieces involved in setting up the Core Data stack. Working through these unit testing techniques has solidified a lot. Analyzing the helper method from the bottom up has made some sense out of how to configure everything:

I need an NSManagedObjectContext whose NSPersistentStoreCoordinator property uses an in-memory store.
To get such an NSManagedObjectContext, I need to add a persistent store with a type of NSInMemoryStoreType to an NSPersistentStoreCoordinator instance. (note the line that’s highlighted)
Of course, in order to do that, I need an NSPersistentStoreCoordinator instance, and I can’t get one of those unless I initialize it with an NSManagedObjectModel.
To get an NSManagedObjectModel, I use the class method, mergedModelFromBundles() to grab it from my main bundle.
Fast-forwarding now: With a proper NSManagedObjectModel instance, I can create an NSPersistentStoreCoordinator instance with it and add an NSInMemoryStoreType to that persistentStoreCoordinator. Finally, I can initialize an NSManagedObjectContext, assign the configured persistentStoreCoordinator to the context, and return it.

Whew! This whole process felt a lot like reading If You Give a Mouse a Cookie, but that may be because I’ve read it a few hundred times to my 2 year old. :]

Writing the unit test(s)

With the ability to get an NSManagedObjectContext instance that’s using an in-memory store, the unit tests using Entities from my Core Data model are quite easy.

Here’s a sample test:

 1import CoreData
 2
 3class TestsUsingModelFromCoreData: XCTestCase {
 4    func testSomethingUsingCoreData() {
 5        let managedObjectContext = setUpInMemoryManagedObjectContext()
 6        let entity = NSEntityDescription.insertNewObjectForEntityForName("EntityName", inManagedObjectContext: managedObjectContext)
 7        
 8        // model setup
 9        
10        // XCTAssert    
11    }
12}

Conclusion

I was so surprised at how straightforward the test was. The helper function makes a world of difference for me. I hope it does for you, too!

You might also enjoy…

Resources

Core Data Fundamentals with Swift

Getting Started with Unit Testing in Swift

Mon, 29 Dec 2014 12:00:50 +0000

Getting set up to write unit tests in Swift, while not difficult, isn’t exactly intuitive. I’ve written several posts and gathered a few resources on unit testing in Swift, but I haven’t yet published a “getting started” guide until now.

Where does one get started with unit testing in Swift when they’ve never gotten started before? Here are 5 steps to help you successfully begin unit testing in Swift:

1 – Create your project

The obvious first step. If you don’t already have a project going, create a new one to organize the code for your app idea. Xcode 6 will automatically generate two “targets” for you. One will be your app’s main module and contains all the code which, when compiled, is meant to be run in the iOS simulator / on an iOS device.

The other will be your test target, which, as the name implies, is where you write your unit test code.

It’s important to note that there are two compilation targets that you’ll be working with as you unit test. Source code that’s part of one compilation target isn’t part of the other by default. This is important to at least know as we move forward in this walkthrough.

2 – Framework considerations: toggle “Defines Module” in your build settings

This step becomes especially critical if you’re using or plan to use a unit testing framework like Quick. It’s not required to use something like Quick, but it can enhance your testing experience if you prefer something other than the out-of-the-box XCTestCase setup.

When you’re working with frameworks, Apple recommends that you make sure the “Defines Module” build setting, found under Packaging, is set to Yes.

If you are relying on, or could be relying on “non-standard” .framework files for your app, make sure you toggle this flag in your Xcode build settings:

3 – Import your main project (module) into your test file(s)

In your test target, at the top of each of your .swift files that contain your XCTestCase classes, write an import statement to bring in your main project’s module. In normal scenarios, your app’s module is named the same as your Xcode project file.

4 – Access control: Public == Testable

Any classes/structs/enums/methods that you need to use in your tests must have a public access control modifier. Internal (default) and private Types and functions can’t be “seen” by your unit tests, so you need to go the public route if you want to test those things.

Previously I’d written on Swift access control and its implications for unit testing. There, I proposed simply adding your main project’s .swift source files to your test target, but 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.

5 – Write tests!

With your main project imported into a test file, and your Types and functions declared with appropriate public accessibility, you’re all set to begin writing tests in Swift!

Summary

We’ve gone from 0 to ready-to-test in this getting started guide to unit testing in Swift. From here, you may be interested in pursuing other topics related to unit testing in Swift. Check out my ever-growing unit testing resource list for more information!

Swift Unit Testing – Verifying Method Calls

Mon, 22 Dec 2014 13:09:28 +0000

In this unit testing screencast for Swift developers, we explore how to use Test Driven Development to verify method calls.

Getting Started Guide

If you’re new to unit testing or are trying to get set up with unit testing in a Swift project, you might check out my getting started guide before jumping into the screencast.

Screencast

Large / Full-Screen Viewing

GitHub Example

GitHub repo of the example developed in the screencast.

Screencast Transcript

[0:01]

Hi, I’m Andrew from andrewcbancroft.com, and I’m bringing you a test driven development example for iOS in Swift.

The goal of this video is to teach you how to write a unit test to verify that a method was called.

[0:21]

I’ll begin in Xcode 6.1.1 with a side-by-side view of my TestCase class, and my primary View Controller class. This is what Xcode generated for me when I chose to create a new Single View Application.

[0:38]

Imagine a scenario with me: Suppose that as part of your application’s requirements, you mush show an Alert View after your primary view loads. How would we go about using Test Driven Development to implement this “feature”?

[0:53]

Well, we’d write a test, of course – I’ll name it something appropriate like “testUIAlertViewShowsAfterViewLoads”

[1:04]

Next, I need to create an instance of my ViewController class so that I can test it.
But immediately, I run into trouble. It seems that my TestCase class can’t “see” my View Controller class.

[1:17]

Thankfully, it’s a simple fix: Simply add the View Controller class to your Test target.

[1:26]

With everything compiling now, we can move to the next line of test code.

[1:32]

First off, in order to test my View Controller’s Alert View functionality, the Alert View has got to be visible to my test. The easiest thing for me to do at this point is to assume that there will be a property on my View Controller that I can set. This allows me to perform a kind of dependency injection known as “setter injection”. All it really means is that the property is dual-purpose. When the app runs on my iPhone, it’ll use a real UIAlertView. But when I run it in my tests, I can plug in a UIAlertView that I control the behavior of, so that I can verify what I need to in my tests.

[2:16]

The ability to swap in a kind of Alert View that I control really is the “magic sauce” to this whole test-driven operation. In order to know whether or not a UI element was “shown” in a unit test without actually showing something on the screen in a simulator or device, I need to invent something known as a test-double. A fake object, if you will.

[2:44]

My Fake Alert View will have some special capabilities that allow me to know whether the “show()” method was called on it. At the same time, it needs to be able to be substituted in my View Controller for a real UIAlertView.

[3:00]

Since Swift supports object-oriented design, we have inheritance at our disposal here.

[3:07]

I’ll create a nested class inside my test function called FakeAlertView. Notice that it’s a subclass of UIAlertView. What’s great about this is that it meets both of my testing requirements: I can control it’s behavior, and it can be substituted anywhere a UIAlertView is needed.

[3:28]

I’ll finish fleshing out this fake object in a minute. Now that Xcode isn’t complaining about not knowing what a FakeAlertView is, I’ll turn my attention to a new compiler complaint: I don’t have an alertView property on my View Controller yet, so I’ll add one.

[3:50]

There’s just a little more setup that’s needed in order to be able to verify that the show method was called. Since show() doesn’t return anything, we need some way to know that its logic was executed. I’ll do two things to expose this:

[4:06]

I’ll have a boolean property called showWasCalled on my FakeAlertView that is initially set to false.
I’ll override the show() method in this fake UIAlertView subclass. Inside the method body, I’ll reassign the value of showWasCalled to true. That will be enough for me to use inside an XCTAssert, which is coming up.

[4:35]

We’re nearing the finish line here. All that’s left is to call my View Controller’s viewDidLoad method, and write my assertion.

[4:44]

The only thing I’d tell you to make note of is that we need to cast the View Controller’s UIAlertView instance to a FakeAlertView so that we can access the showWasCalled property.

[4:57]

Running the test at this point should produce a failing test, which is exactly what we want (because there’s no code that calls the alertView’s show() method in viewDidLoad()).

[5:08]

The last step to this adventure is to write the production code to pass the test. In viewDidLoad, I call my alertView’s show method and re-run the tests.

[5:19]

And we’re green! Which means we’ve managed to successfully verify that a method was called.

[5:27]

Thanks for watching – I have other resources related to Swift and iOS development at andrewcbancroft.com.

Swift Unit Testing Resources

Fri, 19 Dec 2014 12:00:33 +0000

As I’ve researched Test Driven Development practices in general, and for iOS / Mac applications, I’ve been helped by several sources. I’ve also discovered a few things the hard way, so I’m combining and maintaining this list of resources to help point you in some helpful directions as you adventure in unit testing your iOS apps.

Pluralsight Courses

Play by Play: TDD with Brad Wilson – Awesome, awesome course. I learned some really great techniques from this one. The course is geared toward .Net development using Visual Studio, C#, and Moq, but you should still watch it if you’ve got a subscription – the techniques used can be done on other platforms. I’ve been practicing the techniques in Swift (minus the mocking framework).
TDD as a Design Tool – Geared toward web development with JavaScript / AngularJS, but has some useful patterns.

Blogs

How to write unit tests in Swift with XCTest – Josh Brown gives a nice overview of the unit testing capabilities offered in Xcode and how Swift can be used as the testing language of choice.
Swift: Unit Testing Tips and Tricks – @NatashaTheRobot offers some practical advice in a tips and tricks style blog post.
iOS Unit Testing – Some good introductory articles to browse. Offers a few things in Swift, but much of his content is in Objective-C.
Write your first Unit Test in Swift – Learn how to write the most basic, but still useful, Unit Tests in Swift with XCTest.

User Group Talks

Adam Leonard – Test-Driven Development in Swift using Quick (July 2014) – Talk given by @adamjleonard at a Brooklyn Swift Developers Meetup in July.

At andrewcbancroft.com

Don’t Write Legacy Swift – Motivations for testing your code.
TDD for iOS in Swift – What’s the Goal? – Before actually doing Test Driven Development (TDD) for your iOS / Mac app, it’s really important to ask a very fundamental question: What’s the goal? I discuss two goals for testing your iOS / Mac apps.
Improvements to Unit Testing in Swift with Xcode 7 Much of the pain involved in getting set up to write unit tests in Swift has been alleviated by improvements in Xcode 7. This article analyzes these improvements to ease your unit testing workflow.
Getting Started with Unit Testing in Swift – While getting set up to write unit tests in Swift isn’t difficult, it isn’t exactly intuitive. This 5-step guide will get your project set up to write unit tests in Swift.
An (Almost) TDD Workflow in Swift – 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 describe in this post, to help me break through to being productive.
Unit Testing Model Layer with Core Data and Swift – Exploration of testing when your project uses Core Data. This post provides a walk-through of setting up an in-memory data store to test with NSManagedObjects.
Swift Unit Testing – Verifying Method Calls – Screencast showing how to verify method calls in Swift unit tests.
Swift Access Control – Implications for Unit Testing – Pointer on how to make code from your main project visible in your Test project.
Creating “Mocks” and “Stubs” in Swift – Essentially a discovery I made about how to create fake objects and override those objects’ methods. You’d do this to isolate and control the object’s behavior in order to enable or ease the testing process.

TDD for iOS in Swift – What’s the Goal?

Tue, 16 Dec 2014 12:00:10 +0000

Before actually doing Test Driven Development (TDD) for your iOS / Mac app, it’s really important to ask a very fundamental question: What’s the goal? What am I aiming for when I say I want to drive my iOS development with tests?

2 Goals of TDD in iOS

A recent course I watched on Pluralsight called TDD as a Design Tool gave me some insight on two goals for doing Test Driven Development:

Make sure my code is in the right place
Make sure my logic is correct

Let’s take them one at a time…

A place for everything, and everything in its place

Believe it or not, Test Driven Development is an extremely powerful tool for ensuring that code is written in the right place. But what do I mean by “the right place”?

In the object-oriented world, “places” are data structures, such as classes and structs, and their publicly accessible methods.

When I employ TDD in a project, I will tend to be driven to making sure my code ends up in the right place. I’ll give you an example:

Starting Places

When I create a new iOS project, Xcode sets me up with a Storyboard, a blank Scene, and a View Controller. Xcode also generates a Test target for me… BUT a what am I most aware of right from the onset? The Storyboard and the View Controller.

The natural inclination, then is to start dragging things onto the design surface and wiring them up to the controller as Outlets and Actions, and off I go!

It’s like I’m lead to the ever-common temptation to put all my code for a given screen in the application inside its corresponding View Controller.

TDD Tension

While I may be led there, and while it may seem convenient, it would seem that TDD wants to start me off in a different “place” altogether. Since TDD asserts that I should not write any code unless there’s a test requiring it to be written, I’d be driven away from my main project into my Test project. My canvas at that point is a fresh XCTestCase class.

UI at this point is not on my mind. Here, I care more about the foundations of the app itself. I begin to consider the application’s domain, and its behavior apart from its user interface. This is very important if I want to truly write decoupled, modular, maintainable code.

Rather than weigh down my View Controller with tons of responsibility, TDD drives me to try and build separate classes to steward small bits of my application. Those small classes can be tested much more easily than trying to get an enormous View Controller instantiated and configured in my test suite.

This is just one small example of how TDD can get you off on the right track to putting code in its proper place.

Your logic was impeccable, Captain

The second goal of TDD in iOS is making sure my logic is correct, or, as Spock would say, “impeccable”.

Does my application’s code do what it should do? Can I write my code in such a way that I can easily verify it? TDD, by nature, pushes me in the direction of being able to verify the accuracy of my code’s logical outcomes… that is, how it behaves.

Fascinating is a word I use for the unexpected

Testing has this way of setting expectations. One thing I’ve really enjoyed about TDD’s notorious red-green-refactor cycle is that I know certainly and immediately when I’ve messed up (ie, run across a “fascinating” situation in Spock terms).

When I write the test, it should fail the first time. If it doesn’t, I’ve messed up.
When I write the code to pass the test and the test fails, I also know I’ve messed up.

Next Steps

With the fundamental goals of TDD in place, I feel more prepared from a foundational standpoint to venture into actuall test-driven practices for iOS.

I am learning so much in the area of testing – it’s a technique I’m practicing regularly, both in Swift and in C# (for fun and for work, respectively), so as I grow and discover ways to optimize the TDD experience in Xcode / Swift, I’ll be sharing them. Stay tuned!

Don’t Write Legacy Swift

Wed, 10 Dec 2014 12:00:51 +0000

“Legacy Swift”. Is that an odd phrase to you, too?

“Legacy” has connotations such as “old”, “difficult-to-change”, “outdated”, etc. Juxtaposing “legacy” and “Swift” would never have crossed my mind until I read Michael Feathers’, Working Effectively With Legacy Code, where he asserts,

Legacy code is simply code without tests.

What an impact those words had on me as I’ve transitioned over to Swift from Objective-C. If it’s true that legacy code is code without tests, it’s easy to see how you and I could be writing legacy Swift, even though Swift is a brand new language!

And whether you agree with Feathers’ definition of “legacy code” or not (he readily admits the potential for controversy with the definition), I think we can all concede that unit testing our code has many benefits and leads to the ability to consistently, objectively verify the quality of our code at the end of the day.

Legacy Swift == Bad Swift

Unashamedly, Feathers writes,

Code without tests is bad code…With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

My take-away from that quote is this: The only way to consistently, objectively verify whether my code is getting better or worse is to execute it and see if the results are what I expected. I can do this in the Simulator / on my device, over and over and over, opening myself up to a never-ending, time-consuming, error-prone testing cycle, OR I can write automated unit tests and run them every time as I make incremental changes to my software.

Testing is hard (for me)

I have not always been the most successful at writing unit tests. Test-driven development (TDD) is difficult for me at times. I often find myself sitting, staring at the screen as if looking into an abyss, unsure of what I’m supposed to do next. (Any of you TDD-ers who’ve figured out how to imagine the structure of your production code prior to it being written so that a test can be crafted first, let me know your tricks!)

I’m growing in this area of writing testable code, and the tests that go along with it. Admittedly, I’m still in the stages of “this is hard”, sometimes.

I have noticed, though, that coding and testing patterns are emerging in my toolbox that are making this process more and more fluid for me.

Testing is worth it

However difficult it is for me, I’m on board with believing that the effort put in to writing tests is worth it in the end. I wrestle with my code to tame it with tests from the start.

If I’m unable to figure out test-first development on a particular problem, I strive to write the tests as jointly with my production code as possible. At all costs, I try to avoid writing the code and saying to myself, “I’ll come back to the tests later”, because I don’t trust myself to keep that promise.

With every product I’ve written and tested, I can testify to the fact that I feel good about that code. I know it works how I intended it to work. I rest assured that when I make changes, I haven’t broken anything I programmed in another session. The tests help me remember what I intended for my software to do. I’m confident that the patterns that evolved out of the tested code are better than what I’d have implemented if I did without the tests. It’s worth it.

What kind of Swift will you write?

The main goal of this post was to get you thinking. Feathers got me thinking, so I thought I’d pass along the challenge: Don’t write legacy Swift!

The good news is that, as Feathers writes,

[Legacy code is code without tests] is a good working definition, and it points to a solution.

And that solution is straightforward: Begin writing tests for your code, and you’ll avoid writing legacy Swift.