EZSwiftExtensions
EZSwiftExtensions copied to clipboard
Esqarrouth
Need to agree on a mocking framework to use for tests
Certain tests (e. G ui device extensions) require a mocking framework. We need to decide on one.
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.
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.
I agree with Khalian. Test a couple frameworks separately, merge the best one to master and continue using that.
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.
I have almost zero knowledge in devops for iOS, so I don't think I can help much
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?
@pixel4 The sole reason is to increase unit test coverage for most of the UIKit extensions.
@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.
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.
Ok I will write something and send out a PR. Let the collaborators take a look at the writing custom shims approach.