net-a-porter-mobile / XCTest-Gherkin

Gherkin syntax for XCTestCase
Apache License 2.0
254 stars 64 forks source link

XCTestCase stubbed generator from native feature files #55

Open nap-sam-dean opened 7 years ago

nap-sam-dean commented 7 years ago

A script which would run over a feature file and create a stubbed XCTestCase implementation in swift.

smaljaar commented 7 years ago

@nap-sam-dean Do you mean the Gherkin feature files are converted to Swift style gherkin files, or do you mean to generate StepDefiner subclasses with template step definitions? Just to be sure I understand what you exactly want to achieve here. Some thoughts:

  1. Would you then throw away the native Feature File afterwards, or would you need to keep it around?
  2. What happens when the feature files (we share them between iOS and Android) change? Does the swift style feature file then get updated or do you get a complete new one?
deanWombourne commented 6 years ago
  1. I would keep them around, but it would be up to the user of the library if they wanted to version control them of just discard them after the test run.
  2. I would hope that it could create these on the fly (i.e. as a build script?) so if you wanted you could breakpoint them etc, but they would be kept in sync with the feature files. I'd hope that a good file naming scheme would just let feature files be updated instead of just getting a new one each time.
martin-tomes commented 6 years ago

It would be good to keep the .feature files. We want to version them:

Imagine there is a new version of gherkin tests - eg. new scenario in a .feature file - than the tests run and they fail. This alarms the developer and he needs to implement the new scenario. This would prevent updating the .feature file without noticing. At least I hope :)

ilyapuchka commented 6 years ago

On my current project, we are not using feature files but that's something I'm actively looking into

For templating purposes, we can use Stencil. I already have a WIP implementation, but it depends on a few other changes that should go in first (i.e. #119)

This can improve a lot the workflow when using feature files as we could use the same command line tool to invoke xcodebuild with -only-testing option to run a single test, i.e. using VSCode test task (which is good for writing feature files because it has plugin for autocompletion). I didn't check but I suppose with tests added at runtime it does not work, at least on the first run.

This can also help teams who want to migrate from feature files to do it just with on command.