Hi Guille, > I wonder, are there any good practices/recommendations regarding how to share > state between steps?
I think there is basically no difference with a unit test. As I wrote in https://all-objects-all-the-time.st/#/blog/posts/10, under "Shared setup and teardown”, there are a few different ways to cope with different state required by different tests on the same class. My advice would be to create a new class if tests require different state. So I would answer yes to your question "Should this scenario be in a separate feature (shared state?), and all states related to this be in the shared state?” While shared state may be confusing in a unit test, in Hera, and also in Cucumber for Ruby, people can use traits (or Ruby modules) to group steps that use the same state. That way, the different states required by different scenarios can be nicely separated. Even if there are no traits, like in VisualWorks, helper classes can be used to group steps, and instances of those helper classes can carry state. > What kind of heuristics do people use to say things like: > - ok, these two things will be two scenarios of the same feature > - and here, these two need to be in separate features That is a good question. Given that a feature contains different scenarios, people would typically group all scenarios together. But that is not required. You can have different features files in Cucumber that describe different aspects of the same feature (the “Feature:” line at the top would have the same name). In Hera, it would result in different feature methods on different classes. Splitting up a feature is also a way to keep the tests maintainable. > I imagine that a “purist” (:D) would try to make features more > business-oriented. > But I cannot stop thinking that some “ease of implementation” can creep > inside if they simplify the test writing. Yes, features are business-oriented, as they are used to describe acceptance criteria (that is why Hera’s test class is called HeraAcceptanceTest). I guess that with "ease of implementation” you mean that people are tempted to write imperative-style steps, rather than declarative-style steps. For instance, one can write imperative-style steps like this: Given I am on the sign-in page When I enter my email address in the email field And I enter my password in the password field And I press the “Sign in” button Then I see the home page while a declarative style would result in: Given I am signed in where the latter makes abstraction of how signing in should be done. Let’s discuss more at the Pharo Sprint today. Thank you for the support and the good feedback. Best regards, Koen > On 10 Mar 2025, at 15:16, Guillermo Polito <guillermopol...@gmail.com> wrote: > > Hi Koen! > > This is nice indeed! > > I wonder, are there any good practices/recommendations regarding how to share > state between steps? > > For example, > > Let’s say I have a scenario: > > - two browsers do not share state > given that I open *a browser* > and I open *another* browser > when I select Y on the first browser > then the first browser selected blah is X > > Should this scenario be in a separate feature (shared state?), and all states > related to this be in the shared state? > > What kind of heuristics do people use to say things like: > - ok, these two things will be two scenarios of the same feature > - and here, these two need to be in separate features > > I imagine that a “purist” (:D) would try to make features more > business-oriented. > But I cannot stop thinking that some “ease of implementation” can creep > inside if they simplify the test writing. > > Do you have some experience on these things? > > G > >> Le 9 mars 2025 à 10:18 PM, Richard O'Keefe <rao...@gmail.com> a écrit : >> >> I was working on Gherkin-for-Smalltalk myself, but hadn’t got nearly this >> far. You have taken a radically different approach from mine, and I have to >> say that yours is more Smalltalkish than mine. This is brilliant stuff and >> i look forward to the release. >> >> As one of my previous managers used to say, “you’re a hero!” >> >> >> On Mon, 10 Mar 2025 at 8:20 AM, Koen De Hondt >> <k...@all-objects-all-the-time.st <mailto:k...@all-objects-all-the-time.st>> >> wrote: >>> Dear Pharo users and developers, >>> >>> In my series of blog posts on testing, I published a new post on tools for >>> running Gherkin-style test scenarios in Pharo. See >>> https://all-objects-all-the-time.st/#/blog/posts/13. It is an introduction. >>> Future posts will dig into the details. >>> >>> As always, all feedback is welcome. >>> >>> Happy reading! >>> >>> Ciao, >>> Koen >>> >
