Cornichon session is not shared amongst sequential scenarios

[pangiole]

Hi maintainers,

I do not know if it's a defect or a deliberate design but I noticed a Cornichon session does not outlive scenarios. In other words, it seems to me that the Cornichon session lifecycle coincides with its scenario lifecycle and, therefore, it does not span over the next scenario.

Is it a deliberate design because the author wanted to support execution of scenarios in parallel?

I rather wish to implement a feature made of a sequence of two scenarios (one after the other) and therefore, by reading the Cornichon documentation, I understood I shall set the following in the application.conf file:

cornichon {
  executeScenariosInParallel = false
}

But, when I tried to execute:

def feature = Feature("my feature") {
    Scenario("my first scenario") {
       Given I save ("my-key" -> "some-value")
       // and do more ...
    }
    Scenario("my next scenario") {
      Given I show_session
      // ... empty !?!
    }
}

Unexpectedly, the second scenario runs with an empty Cornichon session ( ... mmhhh ... )

I wrote my test the way described above because I wish the first scenario produce a value into the Cornichon session and thereafter the second scenario reuse it ... but ... it seems that each scenario works with its own Cornichon session.

Is there any way to make sequential scenario share the very same Cornichon session, please?
I'm asking for it because, in the world of test engineering is pretty common to reuse the test fixture (think about the "state of the sytem under test") left over by the previous test case. Reusing fixture is referred as the "shared fixture pattern" which I have not been able to apply with Cornichon.

[pangiole]

Dear maintainers,

until you're not replying, I will just apply the following workaround

package object mytester {
  val hackmap = scala.collection.mutable.HashMap.empty[String, String]
}

// ------------
package mytester 

class MyFeature extends CornichonFeature {
  afterEachScenario {
    Attach {
      And I EffectStep.fromSync(
        title = "push Cornichon session to next scenario",
        effect = { session =>
          session.content.foreach {
            case (key, values) => hackmap += key -> values.last
          }
          session
        }
      )
    }
  }

  beforeEachScenario {
    Attach {
      Given I EffectStep.fromSync(
        title = "pull Cornichon session from previous scenario",
        effect = { session =>
          hackmap
            .foldLeft(session) {
              case (session, (key, value)) =>
                session.addValueUnsafe(key, value)
            }
        }
      )
    }
  }

  // scenarios go here ...
} 

I'm sorry it looks like an ugly hack, but it gives me a way not to get stuck ... can you advice for a more elegant solution, please?

[hajoeichler]

I think cornichon follows the rule that is common sense in BDD. E.g.
"Keep each scenario independent. The scenarios should run independently, without any dependencies on other scenarios." from https://saucelabs.com/blog/write-great-cucumber-tests

[agourlay]

Hi @angiolep,

Having one session per scenario is indeed a design decision that was taken on purpose.

Not only it allows parallel execution of the scenarios but it also acts as a form of encapsulation to prevent people from building complex dependencies between scenarios.

Each scenario should be replayable using testOnly featureName -- scenarioName, dependencies must be made explicit via the infrastructure exposed by cornichon.

You mentioned the shared fixture pattern and it is supported in cornichon to some extent.

There are 4 different hooks available for you to work with:

1. running something before the feature (i.e before all scenario)

2. running something before each scenario

3. running something after each scenarios

4. running something after the feature (i.e after all scenario)

According to your comment, I can see that you have already found 2) and 3).
I personnaly use those extensively to prepare the session to pass to the scenario.

The problem with 1) and 4) for the moment is that they are no session aware, they are just useful to perform some global side effect. Improving the current situation is currently tracked in #71

Sadly it is not straight forward to implement in cornichon-scalatest, I might propose this feature only in cornichon-test-framework in the future.

May I ask you what kind of pre-setup you are trying to perform?

Maybe we can find a way to encode it with the existing hooks or maybe I could perform small changes to enable your use case.

I hope I was able to clear things up for you.

[agourlay]

FYI this issue is likely to be closed soon due to inactivity.