Swift 2 + Xcode 7: Unit Testing Access Made Easy!!!!

Posted on June 9th, 2015

One of the biggest challenges to Unit Testing in Swift was the initial setup. Before Swift 2, you either had to make everything public or remember to add all your files to the testing target (more on this in my blog post on testing in Swift here). But as of yesterday, this annoying testing issue has been elegantly solved!

All you need to do is:

1. Create Your Internal Class

I just created a super simple internal Model object in my brand new TestingTests project with one function:

MyModel_swift_—_Edited

Again, notice that I’m not adding this model to my test target and not making the class or my method public!

2. Import with @testable

In your test target, just import the module you want to test using the @testable keyword:

MyModelTests_swift

3. Test Away!

That’s it, now you can use all the internals of your class for testing purposes 🙂

MyModelTests_swift_—_Edited

Thank you Swift team!

Enjoy the article? Join over 14,500+ Swift developers and enthusiasts who get my weekly updates.

Behinder

Great to know. I still try to understand this whole testing stuff in obj-c
andreamazz

Hi Natasha, thanks for sharing
I’m so glad they added this, adding the public access control to stuff that should have been private was bothering me quite a bit, although it led to interesting discussion on what should be tested, and how.
Tomasz Szulc

Great! Thanks for sharing.
Pingback: Michael Tsai - Blog - WWDC 2015 Links()
Dung Nguyen

Thanks for your sharing Natasha.
It would be better if you have a menu bar on your blog. I had alots of difficulties on finding older page.
raul_mpad

Thank you so much for the testable keyword solution to my problems.
I just had a problem with the code coverage’s new feature in Xcode 7 and now it’s gone after so many days trying to figure it out what was happening…
jeremychone

I have xCode 7 beta2, and somehow, even when @testable …, I still need to set my .swift target to the test target? I am on a command line Mac OSX project.
- Nicole Lehrer
  
  Thanks Natasha for your blog and the helpful info. I am having the same issue as @jeremychone:disqus for an IOS project.
  - Nicole Lehrer
    
    This was my bad – I was using
    @testable import swiftFileName
    instead of
    @testable import moduleName
    and it works just as Natasha describes.
    - jeremychone
      
      Hum, I had the moduleName one, but still had add my files to test target. I will give it another try.
      - Zacharias Beckman
        
        Same problems here. Seems like it’s not quite ready for prime time. I tried creating a brand new testing target, adding one new test case, made sure “Enable Testability” is YES, but no go. Definitely not working… perhaps in beta 6… (crossing my fingers! This would be a fantastic feature!)
- Victor Ji
  
  Same problem with Xcode 7 beta 2.
- Mark Anders
  
  Hi @jeremychone:disqus , in the project settings/Build Settings in the Packaging section for your app, did you set “Defines Module” to Yes?
Zack Shapiro

Thanks for writing this little tutorial up, Natasha. IMO this would be a little more useful if the project wasn’t named TestingTests, kind of gets confusing with the actual testing code you’re implementing
Pingback: @Testable keyword in Xcode 7 - iOS Unit Testing()
SHANTANU DUTTA

I am using Xcode 7 beta4, and on adding the @testable keyword before importing the module am getting the ‘No such module ‘ . Though after the @testable keyword, am able to access all the internal swift classes, but it throws this error while compiling for testing. My product module name is set to target name and I have checked this part for main product target. How should I solve this problem ?
- Natasha Murashev
  
  Make sure your Enable Testability option is set to yes in build settings – http://stackoverflow.com/questions/30787674/module-was-not-compiled-for-testing-when-using-testable
  - SHANTANU DUTTA
    
    Hi, Have made the changes initially but there’s no way it is ready to accept the existence of the module. Attaching two more screenshots.
    - euclid1767
      
      Try removing the Test Target entirely and readding. I haven’t dug down to figure out the exact cause, but I had the same problem and this seemed to resolve.
    - Kostapappas Lampros
      
      Product Name is the solution. I had
      different product name than the folder names. Problem solved
- Suragch
  
  I’m having the same problem. (http://stackoverflow.com/questions/32008403/no-such-module-when-using-testable-in-xcode-unit-tests) Did you ever solve it?
  - SHANTANU DUTTA
    
    This method will not work if your project is using both Objective-C and Swift. This method is for only total swift based project. That’s what I found in my project and reading few other blogs
- Dominic Frei
  
  Even though you are talking about a beta and Xcode 7 is now stable, I had that problem within the release version of Xcode 7, too.
  In case someone stumbles upon this post in the future: A clean did help!
Christopher Sanders

Thank you for this! I really needed this!!!
Tyler Williamson

Unfortunately, my classes that are not members of my tests schema are not visible from within their own module. Use of undeclared type ‘ClassName’ from within its own module! Ugh!
Dheeraj

How can I test the private methods in a class?
- Natasha Murashev
  
  You shouldn’t test private methods. But you can test their side-effects in the internal / public methods that use them.
  - Dheeraj
    
    Okay, thanks for replying. Can you suggest few ways to test the code effectively?
    - Steve
      
      Google is your friend.
  - Zacharias Beckman
    
    I agree – testing should generally focus on public APIs/methods… BUT, technically, with @testable you can now test private methods (requires Xcode 7, Swift 2, and some creativity). There have been a few cases where I’ve really, really wanted to know what would happen if, say, a private internal method returned something that it would not normally return. Subclass it, override the method, inject the mock object, and there you go – use @testable if needed to get easier access.
  - Chad Nelson
    
    Why shouldn’t private methods be tested?
    - Steve
      
      Because testing private makes refactoring a problem. Treat your objects like black boxes when testing and then you will be on the right track.
      - DamienSan
        
        I don’t see in what it makes refactoring a problem. On the opposite, the unit testing will ensure your refactoring will be done correctly.
      - Steve
        
        Well let us know how that works out for ya then!
      - DamienSan
        
        Well on young & lagging behing languages like Swift: it’s a mess.
        
        On mature language like Erlang: it’s a bliss. There are 2 differents frameworks included, EUnit for white box testing, Common Test for black box testing.
        
        Each are optimized for a specific use case and covers everything.
  - DamienSan
    
    You should test private methods too: it’s called white-box testing (as opposed to black-box testing). A lot of internal processing can happen in private scope and you need to ensure that each step is going right.
    
    The scope of the function shouldn’t be used as a decision for not testing it.
Nalin

Thanks for the simple but very helpful article.
Btw if anyone else got a similar error like I did “Failed to import bridging header”, I got it working with this change https://github.com/CocoaPods/CocoaPods/issues/2695#issuecomment-72873023
Peter Ivanics

extreme helpful, thank you! <3
Daniele Bernardini

By the way, if you have problems with some class now and done do a good ol’ clean and it will go away
- Anthony Edgar Bernardo Savioz
  
  Thank you!
- Rob_McB
  
  +1 Thank you for that advice also. Just spent 20 minutes puzzling over this.
Oleg Novosad

Hello, I encountered issue: “Cannot import module being compiled” when I tried to use: @testable import ModuleName

How can I fix it? Help please!
Drew Pitchford

So I’ve done this, but I get this error:

Undefined symbols for architecture arm64:

“type metadata accessor for digitaldoorviewer.User”, referenced from:

It’s a linker command error. Have you seen this before and how were you able to fix it if you have?
- Kevin Hirsch
  
  I had the same issue. Turns out you can’t use your app code for UI Tests: https://github.com/Quick/Quick/issues/415#issuecomment-153885307
  - Drew Pitchford
    
    Yes, I’ve seen that link. These are not UITests. They are Unit tests. It’s a really annoying problem.
    - Lars Blumberg
      
      I’m having the same problem. Linker error with “type metadata for XXX reference from: XXX”. Did you find a solution?
lemonkey

Scenario:

* iOS application with a mix of ObjC and Swift classes.
* Unit test class written in ObjC.

Is it possible for the ObjC unit test class to access the public Swift classes in the main target (I don’t think assigning them to both the main target and the ObjC test target would work)? I’m able to import normal ObjC classes that aren’t assigned to the test target into the unit test class and I’m able to create a Swift unit test class and import ObjC classes that similarly don’t have test target membership into it, but not for the ObjC test target importing Swift classes in the main target.

The main target does have module defines module set to YES and its module name is set, which is how I’m able to import the ObjC classes into the Swift based unit test class.

#import “MainTargetModuleName-Swift.h” won’t work since this auto generated header is the value for the SWIFT_OBJC_INTERFACE_HEADER_NAME build setting on the main target, and the test target doesn’t know about it.

Thanks!
Kostapappas Lampros

TestingTests must be the name of the Product Module Name that can be different from the folders name as image show above. That can lead you to search why don’t recognise the ‘TestingTest’. Please add a warning about that.. to save time :)X Very good post:)X Thanks
Nicolás Miari

I still don’t understand why we have to perform this (admittedly, east) step for the unit tests target, but the UI tests target works right out of the box.
goblin

Nice!
It worked for iOS than I tried with Command Line Application but it didn’t work out. Some linker problems
Grant Kemp

Thanks for this lovely simple intro Natasha,
I have referenced it in my GH project

https://github.com/grantkemp/IOS-Swift-Testing-Tutorial-and-Demo/blob/master/IOSTestingKitchenSinkTests/SimpleModelTests.swift
Ace Green

Thanks for the post. In my case, the class is recognized but my functions are recognized as if they are private

for example:

func queryCurrentValue(completion: (JSON) -> Void) { }

when I try to call it in my test:

func testQueryCurrentValue() {

var expectation: XCTestExpectation = self.expectationWithDescription(“QueryCurrentValue Expectation”)

ViewController.queryCurrentValue { (resultsJSON) in

XCTAssert(!resultsJSON.isEmpty, “Query results came back empty”)
XCTAssert(DataCache.defaultCache.readDataForKey(“(queryLink)”, “Data not Cached”))

expectation.fulfill()
}
waitForExpectationsWithTimeout(5.0, handler:nil)
}

I get the error:
‘Use of instance member ‘queryHistoricValues’ on type ‘ViewController’; did you mean to use a value of type ‘ViewController’ instead?’

Its expecting ViewController as a parameter to that function?
- Ace Green
  
  Just an additional note, when I click on BitLive (import) I only see the public classes of my app. Not sure if this is the expected behavior or something is fishy. The “ViewController” class is recognized to it though
Qi Mu

Great, thank you!