Need to agree on a mocking framework to use for tests

[Khalian]

Certain tests (e. G ui device extensions) require a mocking framework. We need to decide on one.

[lfarah]

@goktugyil what's your plan on that?

[Khalian]

The main caveat of a traditional mocking framework is that swift is not support reflection for writes - http://blog.pragmaticengineer.com/swift-the-only-modern-language-with-no-mocking-framework/.

We might have to resort to compile time code generation - https://github.com/SwiftKit/Cuckoo. I am not sure if that is the right approach. As a degenerate case we might have to just write fakes manually.

[Khalian]

I believe the best way to approach this problem would be to write a prototype with a chosen framework (declare it before hand in this issue) and submit a pull request. If consensus is achieved we can declare that as our framework of choice.

I will pick https://github.com/SwiftKit/Cuckoo for testing.

[Esqarrouth]

I agree with Khalian. Test a couple frameworks separately, merge the best one to master and continue using that.

[Khalian]

My status for this right now:-

Podfile :

target 'EZSwiftExtensions-iOS' do
platform :ios, '8.0'
use_frameworks!
pod "Cuckoo"
project "EZSwiftExtensions.xcodeproj"
end

I was able to get the Cuckoo sources down. However this seems extremely counterproductive (requiring the pod sources will add non trivial amounts of time to travis build).

Is there a maven equivalent to the IOS dev ecosystem? Maven just downloads the repos in a directory and defines the JVM classpath to point from that. Given travis's VM based build architecture, the cache wont keep getting wiped across builds.

I must say as of now I am pretty disappointed with the way the IOS ecosystem has argued about devops and build practices.

[lfarah]

I have almost zero knowledge in devops for iOS, so I don't think I can help much

[lfarah]

@pixel4 any help?

[DulMephistos]

I'm not a fan of Cuckoo to be honest.

I know the question was more regarding the issue with having to download the pod source every time, so answering the right question: That's how cocoapods works, you can always commit the /Pods directory to solve this but I don't recommend doing so. Have you tried Carthage? It's not centralized like cocoapods, you could build Cuckoo framework and just commit it in the project. Not so bad to commit a framework in the project, IMO.

My going back to Cuckoo, just to give some context on why I don't like it:
As you said, Swift wasn't designed to support reflection and there's a reason for that. I'm not a fan of going against this principle by generating files on runtime to support mocking. I'm more inclined to embrace the language and follow its guidelines. Reference: http://masilotti.com/better-swift-unit-testing/

Out of curiosity, why do we need UI Test mocking for EZSwiftExtensions?

[Khalian]

@pixel4 The sole reason is to increase unit test coverage for most of the UIKit extensions.

[Khalian]

@pixel4 Whats your take on increasing test coverage on APIs where mocking is necessary (e.g UIDeviceExtensions). I dont like code gen mockups either, but I dont see a way out short of creating my own stubs/spys.

[DulMephistos]

Exactly.. that's the only way out. On the projects I work on I usually have a system in place with protocols to allow stubbing but to be honest I mostly use on network related code.

[Khalian]

Ok I will write something and send out a PR. Let the collaborators take a look at the writing custom shims approach.