TDD on Andrew Bancroft

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!

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.

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!