Swift 3.1 deprecated + initialize in Swift classes

[kerrmarin]

Context

Since upgrading to Xcode 8.3 and Swift 3.1, we encounter the following warning:

Method 'initialize()' defines Objective-C class method 'initialize', which is not guaranteed to be invoked by Swift and will be disallowed in future versions

Currently the NativeTestCase relies on behaviour provided by + initialize to work.

Since we merged #50, NativeTestCase and NativeRunner have similar functionality. NativeRunner doesn't have the limitations of NativeTestCase, but NativeTestCase has the benefit of more meaningful test names. NativeRunner also has an API that feels more natural.

I think for now there's value in keeping both NativeTestCase and NativeRunner.

Possibilities

1. We re-write NativeTestCase in Objective-C. There are some downsides to this like compile times would increase although perhaps only negligibly.
2. Deprecate NativeTestCase and find a way to incorporate its advantages to NativeRunner. Then remove NativeTestCase for 1.0 to remove duplication and reduce API surface. I think we also need to decide if there's any value in having two ways of doing native feature files, especially if we can clean up the implementations and are able to implement XCTestCase stubbed generator from native feature files #55.
3. Implement something similar to this: http://stackoverflow.com/a/42824542/1027644
4. ???

I'd love to hear some feedback from @smaljaar and any other users of the library to hear use cases.

🌮 🚀

[smaljaar]

Use case 1 NativeTestCase
Before we had NativeRunner we struggled with executing a single scenario from Xcode. This problem is solved by the NativeRunner. Still, I like NativeTestCase for how it reuses the Gherkin scenario definition automatically in the XCTest test method name, therefore resulting in nice reporting. If you were to convert that to NativeRunner you once again have to write the scenario name in every test method, this is duplicate work. I'm now thinking of using NativeRunner in a separate file for development purposes only (easy to execute a single feature file/scenario), but by default (on our CI) we will use NativeTestCase to run the tests.

Use case 2 NativeTestCase
We discovered another use case of NativeTestCase that is not supported by NativeRunner. If you are running a feature file that contains multiple scenarios using the NativeRunner, then if continueAfterFailure is set to true, and one scenario fails, then the next scenario is not executed, which is not expected behaviour. In NativeTestCase the next scenario does get executed as expected. The only way to make use of continueAfterFailure = true using NativeRunner is to specify each scenario in a separate test function, which means you have to duplicate each scenario definition into the NativeRunner method call runScenario(featureFile:scenario:testCase:), which is too much work and error prone. For example, when the scenario definition changes, you have to change it in two places.

Feedback to Possibilities mentioned by @kerrmarin

1. Objective C: I don't see much issues with doing this. My experience with mixing Obj C and Swift in the testing target is fine.
2. I think it would be hard to get the test method and reporting generation benefit from NativeTestCase inside of NativeRunner. They do different things. In NativeRunner you have to write the test methods for every feature file or scenario depending on how you want to group them. In NativeTestCase you only have to reference the path to the feature files and reporting is perfectly generated. I commented on XCTestCase stubbed generator from native feature files #55 to get a better understanding of its purpose.
3. Seems like workaround of something that can be easily done in objective C.

[deanWombourne]

Hi everyone - this is a real issue now because in swift 4 it's moved from deprecated to forbidden :(

[kerrmarin]

@smaljaar #80 is an attempt to resolve this, if you'd like to take a look

[smaljaar]

@kerrmarin awesome, I wanted to test this but noticed but pod version isn't updated yet, could you or @nap-sam-dean plz bump the pod version?

[deanWombourne]

@smaljaar Just released as version 0.12 :) (If this works for you we can close this issue :)