Swift TyphoonBlockComponentFactory Error in XCTest

[twyneed]

XCode: 6-Beta5
Typhoon: 2.1.0

i’m using Swift with Typhoon and Cocoapods. Everything worked well until i started to write an Integrationtest (according to the Typhoon-Example-App Test) for my Typhoon component. I wanted to setup the TyphoonFactory in the Test setUp() method in the same way as i did in the AppDelegate. When i execute the test i always get a

TyphoonBlockComponentFactory assertIsAssembly:] + 244: ERROR: MyApp.MyAssembly is not a sub-class of TyphoonAssembly

error thrown by Typhoon (wich is using the kindOfClass method under the hood.) The same code is working perfectly in the AppDelegate and i can’t figure out whats wrong.

To verify this behavior i implemented the isKindOfClass check in booth classes (see code below):

• AppDelegate -> true
• MyComponentTest -> false

PodFile

inhibit_all_warnings!

target "MyApp" do
pod 'Typhoon', '2.1.0'
end

target "MyAppTests" do
pod 'Typhoon', '2.1.0'
end

MyAssembly.swift

public class MyAssembly : TyphoonAssembly {
    //Some definitions
}

AppDelegate.swift

func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: NSDictionary?) -> Bool {
    …
    var assembly : MyAssembly = MyAssembly()
    //Always returns „true“
    println("Is type of class: \(assembly.isKindOfClass(TyphoonAssembly))")
    …
}

MyComponentTest.swift

import XCTest
import MyApp

class MyComponentTest: XCTestCase {

    override func setUp() {
        super.setup()
        var assembly : MyAssembly = MyAssembly()
        //Always returns „false“!
        println("Is type of class: \(assembly.isKindOfClass(TyphoonAssembly))")

        //Error is thrown „MyApp.MyAssembly is not a sub-class of TyphoonAssembly“
        var factory : TyphoonComponentFactory = TyphoonBlockComponentFactory(assembly: assembly) as TyphoonComponentFactory
    }
}

[jasperblues]

Thanks for reporting. . we'll investigate.

Out of interest, what happens when you edit the file resolved by CocoaPods and remove that line? (Its only there safety purposes against incorrect code). Does everything otherwise proceed normally?

Would you care to email a sample project to: [email protected] ?

[alexgarbarev]

Hi @RobbieBubble , thanks for reporting.. I had same problem in objective-c, when using cocoapods and test target.

The test target was set using test host, i.e. attaching to running application of main target.
The problem was, because main target and test target had Typhoon dependencies in cocoapods.
This is a problem, because CocoaPods adds Typhoon twice, and there is two instances in memory at same time.
When I print:

NSLog(@"Assembly base class: %p", [TyphoonAssembly class]);

I had different addresses in test and main target at same. It is very serious problem.

To fix, try to remove Typhoon from your test target, then run pod install/update and clean all derived data/build clean and try test agian

[jasperblues]

@alexgarbarev Nice investigation.

@RobbieBubble In my experience when removing dependencies from test target, certain situations can leave stale files.

To be safe, what I do is:

• Remove the Pods folder
• Remove the workspace file
• Remove the generated pods lib from both targets.
• Remove the pods build phase from both targets

Instead of running pod update, run pod install again.

[twyneed]

@alexgarbarev
Awesome!
That solved the problem!

The Podfile has to look like

inhibit_all_warnings!

target "MyApp" do
pod 'Typhoon', '2.1.0'
end

target "MyAppTests" do
end

instead of

inhibit_all_warnings!

target "MyApp" do
pod 'Typhoon', '2.1.0'
end

target "MyAppTests" do
pod 'Typhoon', '2.1.0'
end

@jasperblues
I also followed your instructions of getting rid of all artifacts.

Actually i had this in mind that the inclusion of Typhoon in the Test-Configuration might cause problems but i've never removed it because i thought i need it so that i can use the Typhoon-classes in my testcase.

Thx for your support and sorry for bothering the Typhoon Group with "non Typhoon related" problems

[jasperblues]

@RobbieBubble Not at all, thanks for reporting the issue, we always appreciate feedback, and we're very happy to here about your progress with Typhoon and Swift.

[jasperblues]

ps: For the old-style logic tests it was necessary to include the dependencies in both targets.

But as @alexgarbarev mentions, we have TEST_HOST set, or in other words Application-style tests, then the tests will inherit all dependencies from the main target. Application-style tests are the default almost everywhere now.

We can still add some further dependencies (eg matching libs, etc) explicitly to just the test target using eg:

target :tests, :exclusive => true do
    pod 'OCMockito'
end