Architecture of tests with multiple features

[ryansands-muzz]

Not actually a bug, however was the most appropriate choice (sorry).

Issue: Library is forcing us to write all our tests under a single test case which makes storing state difficult. If we have 2 feature files, with a shared step with a data table, what is the best practice to access this data for that specific Scenario.

We are trying to maintain a clean architecture so are splitting up our files to have single responsibility. Currently we can use a singleton to store and share state, however this doesn't feel like best practice.

In our specific case we have a shared Given step that contains the email in the data table, we want to use this step for 2 different Scenarios in 2 different Features, I have written an example of our current setup below, could you please advise on how we should actually be going about this however?

class BaseState {
    static let shared = BaseState()

    var username: String = ""
    var password: String = ""

    func reset() {
        username = ""
        password = ""
    }
}

extension Cucumber: StepImplementation {
    public var bundle: Bundle {
        return Bundle(for: BaseUITests.self)
    }

    var baseState: BaseState {
        return BaseState.shared
    }

    public func setupSteps() {
        AfterScenario { [self] _ in
            self.baseState.reset()
        }

         sharedSteps() // In here we have a Given step with a data table that gives us email and password
         loginFeatureSteps()
         menuFeatureSteps()
   }

   private func sharedSteps() { 
         sharedGivenStep()
   }

We would like to access the data from the table in the shared step in these features below

extension Cucumber {
    public func loginFeatureSteps() {
         givenSteps() 
         whenSteps()
         thenSteps()
   }

extension Cucumber {
    public func menuFeatureSteps() {
         givenSteps()
         whenSteps()
         thenSteps()
   }

We could obviously pass the data through the methods, storing them in the setupSteps method, however this isn't scalable with lots of tests and variables, of which most tests don't care about.

[Tyler-Keith-Thompson]

I'm gonna find time this weekend to give you a more thought-out response. For now, I want to get you some very off-the-top-of-my-head ideas.

The first is that your loginFeatureSteps/menuFeatureSteps/etc... don't have to be functions. They could easily be classes (or structs), and you could inject state into those classes or structs with your preferred method for doing just that.

The next is that you could use the DSL. That DSL executes features immediately, rather than relying on a setup method that is injected before tests run. In other words, if you're using the DSL you can use it in conventional XCTestCase classes.

You could also use a dependency injection framework, like Swinject, for BaseState. It may feel a little bit better than a singleton pattern.

Lastly, you actually have access to fully parsed objects from each step. So for example: Given("some thing") { _, step in }. Step has a scenario property. So it's possible to query that Scenario for all of its Steps and get the datatable off of them. This feels gross because it starts to tightly bind your BDD tests to execution order, which is generally an anti-pattern.

Obviously, none of these stand out as perfect, some of them are going to be highly dependent on your project particulars. Like I said I'll take some time and give you a better thought-out answer and perhaps a recommendation as I have a little more time.

[ryansands-muzz]

Hi Tyler, thanks for the reply, we've actually solved this by just making tests that we want to share data across as Scenario Outlines, even if it's only for one example, this has allowed me to remove the state manager and still only requires me to pass the XCUIApplication around which we do inside of structs and using page object pattern now