Swift test give error "Undefined symbols for architecture x86_64"

Question

I'm running swift test from the command line to run the test cases. This is the test case:

import XCTest
@testable import vnk_swift

class KeyMappingTests: XCTestCase {
    static var allTests : [(String, (KeyMappingTests) -> () throws -> Void)] {
        return [
            // ("testExample", testExample),
        ]
    }

    func testExample() {
        let keyMapping = KeyMapping()
        XCTAssertNotNil(keyMapping , "PASS")
    }
}

And here is the output message.

If I remove the usage of KeyMapping, everything works fine:

    func testExample() {
        // let keyMapping = KeyMapping()
        XCTAssertNotNil(true , "PASS")
    }

Looks like there is a problem when I'm trying to use a class. How do I fix this?

(I did not use Xcode for this project as I started with swift package init, the source code for this project is here: https://github.com/trungdq88/vnk-swift)

if you build the project, can you find a .o file for KeyMapping.swift? — Jochen Bedersdorfer, Dec 29 '16 at 17:15
here's a guide to unit testing that you might have seen already, but maybe it helps: http://riis.com/blog/swift-unit-testing/ — Jochen Bedersdorfer, Dec 29 '16 at 17:18
@JochenBedersdorfer Yes I can find `KeyMapping.swift.o` inside `.build/vnk_swift` directory. — Tony Dinh, Dec 30 '16 at 00:24

Cristik · Accepted Answer · 2019-02-01T07:04:17.283

I managed to successfully build and test your package by doing the following modifications:

renamed the package name to VnkSwift, for some reasons the build tool doesn't like dashes in package name, nor it works when you have underscores in the generated package name (so renaming the package to vnk_swift to make sure the import statement and the package name match didn't work)
renamed the test folder to VnkSwiftTests in order for the linker to know what to link against; seems this is a precondition for the linker to know to link against the package
finally, renamed main.swift to something else (I used utils.swift). The thing is that the presence of main.swift instructs the build tool to generate an executable, and linking against an executable doesn't work very well. After the rename, had to comment the if code, as global running code can only belong to main.swift.

To conclude:

Avoid non-alphanumeric package names
Package name and test directory name must be in sync
Make sure you don't have a main.swift file to make sure the package can be linked against

Why can't a unit test target link against executables?

It's because both the test bundle and the executable bundle have global executing code (aka the main function), so the linker doesn't know which one of them to pick. When testing from Xcode, the test bundle runs into the context of the application - it doesn't link against it, like in the situation right here.

Xcode also has this problem when creating a command line tool - you can't unit test that target, if you want to unit test the code then you have to create a library that will be linked by both the tool and the unit test target (or include the files in both targets)

Thanks, it works. But what is wrong with linking against an executable? So right now I can't test an executable package on OSX due to a swift error? — Tony Dinh, Jan 01 '17 at 11:01
`Package name and test directory name must be in sync` was not at all obvious to me-- that cured my issue!! Thanks! — Chris Prince, Jan 20 '17 at 01:25
Not a good solution. Renaming `main.swift` makes the package something else but not `executable`. You can't run `swift run` on this package. Though @Frank's answer is not elegant but it seems the simplest way having an executable Swift package with tests at the moment. Really sad. — Rostyslav Druzhchenko, Dec 10 '19 at 19:23
@RostyslavDruzhchenko Frank's solution is similar to this, the difference is that he kept the app module, but for unit tests used the same approach by using a library. The bottom line is that you cannot test an executable binary, and that's not SPM's fault. — Cristik, Dec 11 '19 at 06:27

score 31 · Answer 2 · edited Sep 13 '19 at 11:03

This seems to be caused my having a main.swift in your module directory. This results in an executable being build, instead of a library against which your test cases can be linked.

I resolved this issue by splitting my code into two modules. A library for which I have test cases and the application that only contains main.swift:

Package.swift
Sources\FooBarLib\
Sources\FooBarLib\Something.swift
Sources\FooBarLib\MoreStuff.swift
Sources\FooBarApp\main.swift
Tests\FooBarLibTests\TestSomething.swift

Then in my Package.swift make sure FooBarApp depends on FooBarLib:

import PackageDescription

let package = Package(
    name: "FooBar",
    targets: [
        .target(name: "FooBarLib"),
        .target(name: "FooBarApp", dependencies: ["FooBarLib"])
    ],
)

Then in TestSomething.swift you import the FooBarLib module:

@testable import FooBarLib
import XCTest

class TestSomething: XCTestCase {
    func testFunc() {
    }
}

This really helped me to solve exactly this problem. One note for others, in the case you structure your code as suggested it also means that you have to code your `FooBarLib` "library" as a library. So your classes, structs, methods, etc. have to be made public before you can use them in your main.swift file. — Fred Appelman, Jun 17 '17 at 08:49
It's the `having a main.swift in your module directory` for me too. Thank you! — Surpher, Sep 25 '17 at 09:56

score 5 · Answer 3 · edited Apr 02 '20 at 07:22

5

In Swift 4, check if your .testTarget depends on FooBarLib.

    .testTarget(
        name: "FooBarLibTests",
        dependencies: ["FooBarLib"]),

edited Apr 02 '20 at 07:22

Bhargav Rao

50,140
28
121
140

answered Feb 13 '18 at 08:57

Jianing

111
2
4

score 1 · Answer 4 · answered Jan 18 '17 at 03:27

Building off of @Cristik's answer, really it comes down to what is in your Sources folder. For me, I had an folder in Sources that needed to be exactly the same as what was in Tests except that what is in Tests needed to be suffixed with Tests. So, if you have Sources -> Foo-Bar, you had to have Tests -> Foo-BarTests. NO EXCEPTIONS.

One other note: all dashes will be converted to underscores so at the top of your test files, you'll have to add @testable import Foo_Bar.

score 0 · Answer 5 · edited Nov 20 '18 at 11:21

0

I see that in the directories you have vnk-swift, but in import statements and in the mangled name you have vnk_swift. Maybe this is an Xcode/compiler bug with handling hyphens. Try to reproduce on a directory and project without a hyphen in the name, just vnkswift for example.

Hope it helps

edited Nov 20 '18 at 11:21

ricardopereira

11,118
5
63
81

answered Dec 31 '16 at 11:13

Alistra

5,177
2
30
42

Yeah I noticed that too, I tried with VnkSwift but no luck :( – Tony Dinh Dec 31 '16 at 11:15
Will do that again in a new branch with `vnkswift` name. – Tony Dinh Dec 31 '16 at 11:16

score 0 · Answer 6 · edited Mar 15 '19 at 10:25

0

In my case, I enable the test by go to show test navigator in Xcode, right-click and enable the test. And it worked.

edited Mar 15 '19 at 10:25

pkamb

33,281
23
160
191

answered Aug 31 '17 at 03:59

Cao Văn An

113
1
2
5

score 0 · Answer 7 · answered Jul 30 '21 at 11:18

0

In my case after migration a framework project to link other frameworks as XCFramework instead of universal frameworks, some tests can not be compiled in the linking step.

My fix is converting those failed objc tests to Swift and the issue is solved.

answered Jul 30 '21 at 11:18

Bill Chan

3,199
36
32

score 0 · Answer 8 · answered Jul 13 '22 at 23:50

Make sure you are using a Unit Testing Bundle as your target.

For me, that was the problem.

Xcode used to ask, while creating a project, if we wanted to add Unit Testing first and a second option for UI Testing. But now, starting from Xcode 13, the only option is

Blockquote

which automatically will create UI Testing Bundles.

I got this solution from here.

You can differentiate by the icons:

score -3 · Answer 9 · answered Apr 05 '20 at 14:47

-3

If you are adding TestTarget after creating pod file. Then below code may be missing in the pod file.

target 'DemoTests' do
  inherit! :search_paths
  # Pods for testing
end

Add above code before end of target like below.

target 'Demo' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for DocsDemo

  target 'DemoTests' do
    inherit! :search_paths
    # Pods for testing
  end

end

answered Apr 05 '20 at 14:47

Yogendra Singh

2,063
25
20

This question is about Swift Package Manager, not CocoaPods. – Cristik Mar 30 '21 at 19:17

Swift test give error "Undefined symbols for architecture x86_64"

9 Answers9

Linked