Add public accessors for types to begin supporting XCode 6 beta 4.

[drmohundro]

This is the first step in getting Nimble ready for XCode 6 beta 4.

The following things are included in this:

• public accessors added
• removed the bridging header (not supported in Frameworks)
• forward declared NMBExpectation (was getting an error related to it)

I'm still getting an error related to:

Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_NMBExpectation", referenced from:
      objc-class-ref in DSL-B83371164C24FC7F.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

But I'm unfamiliar with what the problem is here.

I thought this might help in terms of getting a start, though. I'll continue to try to resolve the "undefined symbols" error as well.

[blindsey]

return range && range!.startIndex == actual.startIndex

[jeffh]

Hey @blindsey, bridging headers don't seem supported for frameworks anymore, but due to the way Swift classes are generated -- they aren't normal Objective-C classes, you cannot forward declare them without the proper swift attributes. This might be a bug to file to Apple, but more investigation is required first.

I'm currently limited in time right now, but I'll try to check it out this weekend.

[blindsey]

@jeffh I'm struggling with getting the tests to run after removing Nimble-Bridging-Header.h. The 'expect' func isn't exported anymore. Curious to see what your investigation turns up.

[sync]

@drmohundro

remove:

@interface NMBExpectation : NSObject
- (id)initWithActualBlock:(NSObject *(^)())actualBlock negative:(BOOL)negative file:(NSString *)file line:(int)line;
@end

make NMBExpectation and init method public:

public class NMBExpectation : NSObject { ...

public init(actualBlock: () -> NSObject!, negative: Bool, file: String, line: Int) {

then it will compile 👍

[drmohundro]

@blindsey thanks - got the conditional checks around range corrected. @sync got NMBExpectation working. I could've sworn I tried that, but clearly I didn't and I'm still trying to learn how Swift and ObjC work together. 👍

The next steps I believe are to get the tests passing, which is what @blindsey was referring to I believe.

[drmohundro]

Good catch - corrected. Right now, I'm dealing with BasicMatcher not conforming to Matcher protocols. I'm not sure if I messed up something while adding public accessors to get things to compile or if it's a compilation difference between beta 3 and beta 4.

[drmohundro]

Made it quite a bit farther now... I'll try to summarize what's happened and ask for some eyes/feedback on what I've done, because I may have taken some missteps.

• First off, I made the Matcher protocol inherit from BasicMatcher - it seemed to simplify some operations and also leads into the next bullet...
• I was running into "invalid redeclaration" errors around the to extension method and the actual implementation that lives on Expectation. I ended up leaving those methods internal and renaming them to toImpl and toNotImpl. This way, the only public to methods that will be accessed are the extension methods.
• failsWithErrorMessage in the test utils is crashing the test runner. I'm not sure why yet.
• testArrayEquality is failing to compile right now, specifically the calls that take an Array<Int> in as opposed to an array literal (like [1,2,3]). Not sure about that yet.

If I exit out of failsWithErrorMessage early and comment out the 3 lines in testArrayEquality, all but 5 tests pass.

Let me know if I'm way off base or anything with these changes! Thanks!

[atermenji]

@drmohundro as for testArrayEquality:
In the newest XCode compiler now complains to [T] not being Equatable in the func equal<T: Equatable>(expectedValue: T?).

I guess this is a normal behaviour, because Swift Array is not Equatable.

There are several ways to bypass this restriction:

1. Use NSArray instead of an Array
2. Write expectation in different style:

expect(arrayOne == arrayTwo).to(beTrue())

1. Overload equal function to support Arrays somehow like this

func equal<T: Equatable>(expectedValue: [T]?)

We are facing the same problem in our similar framework and we've decided to use NSArrays instead of Arrays by now.

[tonyd256]

@drmohundro I cloned your branch and tried out a few things. I got stuff mostly working by adding these things:

extension Array: Equatable {
}

public func ==<T>(lhs: Array<T>, rhs: Array<T>) -> Bool {
    return lhs.bridgeToObjectiveC() == rhs.bridgeToObjectiveC()
}

extension Optional: Printable {
    public var description: String {
        switch self {
        case let .Some(value):
            return toString(value)
        default: return "nil"
        }
    }
}

Finally, on line 40 of BeEmptyTest.swift replace "<(1)>" with "<[1]>"

There are still 3 (2 really) tests that fail. The async wrapper and the identical to message test.

[tonyd256]

Also, there was a typo in Contain.swift ... line 20 should read: return range && !range!.isEmpty ... there was a logical negation missing.

[tonyd256]

OK ... figured out the Async issue:

In AsyncMatcherWrapper.swift, in the Expectation extension, use toImpl() and toNotImpl() instead of to() and toNot(). Should look like this:

extension Expectation {
    public func toEventually<U where U: BasicMatcher, U.ValueType == T>(matcher: U, timeout: NSTimeInterval = 1, pollInterval: NSTimeInterval = 0.1) {
        toImpl(AsyncMatcherWrapper(
            fullMatcher: FullMatcherWrapper(
                matcher: matcher,
                to: "to eventually",
                toNot: "to eventually not"),
            timeoutInterval: timeout,
            pollInterval: pollInterval))
    }

    public func toEventuallyNot<U where U: BasicMatcher, U.ValueType == T>(matcher: U, timeout: NSTimeInterval = 1, pollInterval: NSTimeInterval = 0.1) {
        toNotImpl(AsyncMatcherWrapper(
            fullMatcher: FullMatcherWrapper(
                matcher: matcher,
                to: "to eventually",
                toNot: "to eventually not"),
            timeoutInterval: timeout,
            pollInterval: pollInterval))
    }
}

[tonyd256]

That only leaves issues with the error messages. It seems the actual Nimble lib works for beta 4.

[tonyd256]

ugh ... ok that seemed silly .. I got everything passing ... I'll PR into here and to @drmohundro's fork. Not sure how you want to handle getting all this in.

[drmohundro]

Thanks @tonyd256 and confirmed, everything builds and all tests pass on my box, too!

👍

Looks like either this PR or #10 should get beta 4 compatibility working.

[jeffh]

Great work everyone!

I've been getting some weird test crash when the exercising beCloseTo(within:) on both swift and ObjC variants of Nimble.

@drmohundro, could you try running ./test.sh full and see if you get any errors?

[drmohundro]

Interesting... I am getting failures while running ./test.sh, just not when running the tests in XCode. It does look like it is in the tests related to beCloseTo. Let me dig on that some.

[jeffh]

@drmohundro, I think it might be related to the simulator variant. iPhone 5s and iPad Air sims seem to be fine, but all the other ones are broken.

I'm tempted to write this one up as a swift compiler bug.

[drmohundro]

Interesting... you're right, I can repro it within XCode by using iPhone 4S simulator as an example. Here's a screenshot if anyone has any good ideas. I was going to say it might have something to do with the Expression instance getting cleaned up, but as far as I can tell, everything is a struct at this level of the call stack (so no deinit).

[jeffh]

I've merged #10, which includes these changes too. I'll open new issues for this problem (it might be filed to apple). Also, I prefer to not have operator overrides and have them specified in the matchers instead.