Hi Noury,

I am glad that you enjoyed reading the blog post.

About the pragma. There are 3 reasons:

1. Readability. The elements of the array are very close to the step itself. 
That is also the reason that the first element is a symbol without the hash 
sign and the first letter is an uppercase letter. For a step in a script like:
        Given I have credentials to sign in
the array elements are:
        Given 'I have credentials to sign in’

2. It is not mentioned in the post (I keep it for another post), but there are 
variations when step arguments come into the picture. For instance, for:
        When I fill in the field labeled “First name:”
we need a step definition with a pragma:
        <heraStepDefinition: #(When match 'I fill in the field labeled 
{string}’)>
otherwise we would have to define a new step for each field we like to fill in.
In the example, the step definition includes an argument {string} that will 
match any string between double quotes. That is the Cucumber way to add 
arguments to a step definition. There are other arguments, like {int}.
If the Cucumber arguments are not appropriate, it is possible to use regular 
expressions. Here a step definition pragma for the example step:
        <heraStepDefinition: #(When regex 'I fill in the field labeled 
"([^"]+)"’)>
I chose to put extra symbols in the array argument of the pragmatic instead of 
inventing new pragmas.

3. I wanted to restrict the search for step methods to methods with one pragma, 
not three.

It is just a choice. Who knows what the future brings :-) It is good that you 
made me think about the choice again.

About empty steps. Yes, I find that annoying too. I plan to let Hera generate a 
step definition method that raises a “Step not implemented yet.” exception that 
can be nicely reported in the Hera Runner, similar to the “Step definition not 
found.” exception that is raised when no step definition can be found. This 
aspect is not present in the blog post, but it is similar to the ERROR and 
FAILED indications that are demonstrated in the blog post.

Thank you for the feedback and your support.

Kind regards,
Koen

> On 14 Mar 2025, at 13:28, Noury Bouraqadi <bouraq...@gmail.com> wrote:
> 
> Hi Koen,
> 
> I've read the blog post and enjoyed it. Here are a couple of comments:
> 
> - The step definition pragma is like: <heraStepDefinition: #(Given 'I have 
> credentials to sign in')>
> Why didn't you use a keyworded selector like: <heraStep: #Given definition: 
> 'I have credentials to sign in'>
> 
> - What happens if a step method is empty, i.e. it was generated from Gherkin, 
> but not modified by the developer? In Pharo an empty test method passes. I 
> dislike it. I think any test method without assertions should fail. This 
> change will break smoke tests. So, we need to introduce an assertion message 
> or a pragma dedicated to smoke tests.
> 
> Best,
> Noury
> On Sun, Mar 9, 2025 at 2:37 PM 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
>> 
> 
> 
> 
> --
> Noury Bouraqadi

Reply via email to