Featured on Andrew Bancroft

Managing Xcode Project Dependencies with CocoaPods

Wed, 03 Feb 2016 18:23:49 +0000

Course Outline

I try to get as practical as possible in the course. As you’re watching you’ll be “embedded” into a team of iOS developers, and you’ll explore the problems that CocoaPods can solve for you by watching the team struggle through not having a dependency manager, and then sharing in their victories as they bring in CocoaPods to ease that dependency management struggle.

The course is a progressive journey. First, the team has problems managing dependencies without a dependency manager. Then, they bring in CocoaPods to help them find and organize 3rd party libraries. Then, they start to think, “Hey, what if we could create our own CocoaPod libraries?”. Finally, they use that knowledge of how to create a CocoaPod library to set up a private repository to share code internally between projects with their team.

I’ve got four modules that cover the following topics:

1 - Introducing Project Dependency Management

I teach the basic concepts and definitions associated with “project dependency management”. What is it all about? Why does it matter? And most importantly, how is it done in the Apple Ecosystem?

2 - Managing Dependencies with CocoaPods

I guide you through installing CocoaPods, configuring your Xcode project to use CocoaPods, and working with the CocoaPods command line utility.

3 - Creating CocoaPod Libraries

This is where things turned really fun for me. :] In this module of the course, I teach you how to create a CocoaPod library, host its source code on GitHub, and publish the library to the CocoaPods Trunk.

4 - Hosting a Private CocoaPods Repository

As the capstone to the course, I teach you how to set up a private spec repository and how to configure CocoaPods to utilize it. It really is the culmination of everything learned in the prior modules, but it’s also one of the most practical strategies for sharing code between your various Xcode projects that I’ve found to-date.

In addition to the four modules of content, the course comes with an example Swift iOS app if you’re a Pluralsight Plus subscriber!

Something for Everyone

The course is targeted at beginning to intermediate level developers. I assume no prior knowledge of how to work with a dependency manager.

That being the case, I do my best to offer something for everyone. If you’ve never used a dependency manager on another platform before, I’ve got you covered – I’ll take you step by step through using CocoaPods.

If you’re already using CocoaPods in your Xcode project, maybe you can benefit from the modules on creating CocoaPod libraries yourself! If you’re already creating libraries and contributing to the open source community, what about setting up that private spec repository to share with your team internally?

Feedback Welcome!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

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.