March 2025 - Pharo-dev - lists.pharo.org

Fwd: IWST deadline extension

by Guillermo Polito

Apologies for multiple receptions! > DÃ©but du message rÃ©expÃ©diÃ© : > > De: Guillermo Polito <guillermopolito(a)gmail.com> > Objet: IWST deadline extension > Date: 28 mars 2025 Ã 5:08:37â¯PM UTC+1 > Ã: Gordana Rakic via Esug-list <esug-list(a)lists.esug.org> > > Dear all, > > due to several requests, we have extended the submission deadlines for the call for presentations. > Please check the info below: > > -------- > > IWST is the International Workshop on Smalltalk Technologies. The goal of the workshop is to create a forum around contributions and experiences in building or using technologies related to Smalltalk. While the maturity of presented ideas and results is not crucial, their presentation is expected to trigger discussion and exchange of ideas. The topics of your paper can be on all aspects of Smalltalk, theoretical as well as practical. Authors are invited to submit research articles or industrial papers. > > https://esug.org/2025-Conference/IWST2025.html > > This year we will again have two different tracks: > > Two-Round Paper Submission. As in the previous year, submission will be in two rounds: > Extended abstracts are submitted to present at the conference > Later, full/short papers are submitted for proceedings publications > > Presenting Previously Published Works. We also invite authors of contributions related to IWST's topics, accepted for publication in Journals and Proceedings of top-rated international conferences within the previous 2 years, to submit an abstract and present their published results to the IWST workshop collocated with ESUG. Authors will be invited to present their paper after checking that the submission meets the above criteria. Having the submissions already reviewed and accepted by the peers, they will not be reviewed again for technical content. > Important Dates > > Extended abstract submission deadline: April 7th, 2025 > Already Published Papers Abstract submission deadline: April 7th, 2025 > Extended abstract notification deadline: April 14th, 2025 AoE > > Already Published Papers Abstract notifications: April 14th, 2025 AoE > Full/short paper submission deadline: May 19th, 2025 AoE > > Workshop: July 1-4, 2025 > > Best regards, > IWST team

March 28, 2025

Re: [Pharo-users] "Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Koen De Hondt

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 <guillermopolito(a)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 <raoknz(a)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 <koen(a)all-objects-all-the-time.st <mailto:koen@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 >>> >

March 28, 2025

Re: "Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Koen De Hondt

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 <bouraqadi(a)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 <koen(a)all-objects-all-the-time.st <mailto:koen@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

March 19, 2025

ESUG 2025 Registration opened

by stephane ducasse

Hello Just a little email to announce that the registration for the conference is now opened. https://registration.esug.org/ESUG <https://registration.esug.org/ESUG> And do not forget to submit your talk. S > > ESUG 2025 Call for Presentations > from Tuesday 1st to 4 th of July 2025 > Gdansk Poland > https://esug.github.io <https://esug.github.io/> > https://esug.github.io/2025-Conference/conf2025.html > > > You can support the ESUG conference in many different ways: > - Sponsor the conference. New sponsoring packages are described at https://esug.org/become_sponsor.html > - Submit a talk, software to the award competition, or a paper to IWST https://esug.github.io/2025-Conference/IWST2025.html > - Attend the conference. We'd like to beat the previous record of attendance (180 people at Koln 2019)! > - Students can get free registration and hosting if they enroll in the the Student Volunteers program. See below. > > New this year: a 3 days lectures will be organised before the conference following the isLoop summerschool principle > https://isloop.pharo.org/ > > ## Developers Forum: International Smalltalk Developers Conference > > We are looking for YOUR experience on using Smalltalk. You will have 30 min for presentations and 45 min for hands-on tutorials. > The list of topics for the normal talks and tutorials includes, but is not limited to the following: > - XP practices, Development tools, Experience reports > - Model-driven development, Web development, Team management > - Meta-Modeling, Security, New libraries & frameworks > - Educational material, Embedded systems and robotics > - SOA and Web services, Interaction with other programming languages > - Teaching Pearls and Show us Your Business > > > We added two types of sessions in addition to the regular talks and ''Show us your project'' sessions. > - Show your business in a 10-minute session (Get prepared!!) > - Teaching pearls: we want some sessions on how to teach some design aspects. We want your tip and tricks to teach Smalltalk or OOP. > We expect to have several 10 to 15-minute sessions aggregated. > > ### How to submit? > > Make a Pull Request here https://github.com/ESUG/esug.github.io/tree/source/2025-Conference/talks > [Or but only if you are not connected to the worldâ¦ send an email to stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>] > > Title: [ESUG 2025] Please follow the template below the email will be automatically processed! > Name: > Email: > Abstract: > Bio: > > ## Call for Student Volunteers > Student volunteers help keep the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. > > Pay attention: the places are limited so do not wait till the last minute to apply. > > Conference details: > Send an email to Steven Costiou <steven.costiou at inria.fr <http://inria.fr/>> and Oleksandr Zaitsev <olk.zaytsev at gmail.com <http://gmail.com/>> with: > > title: [ESUG 2025 Student] > name, > gender, > university/school, > country, > email address > want to attend the isLoop lectures (https://isloop.pharo.org/) > short description of you and why you are interested in participating > > For which period is accommodation covered? Accommodation is covered from Monday 30 th June to 4th July 2025. > If you attend the isLoop lectures the saturday and sunday nights will be covered. > Students will be hosted in student rooms. ESUG additionally covers the lunches during the week and one dinner. > > This year the isLoop schools is organized the Satruday, Sunday and Monday before the conference (soon at https://isloop.pharo.org/) > > Duties include handling registration as people arrive at the conference, collecting presentation slides for ESUG right after the presentation is given, being present at an information desk to answer questions, and generally being helpful. Student volunteering makes the conference better, takes a fairly small amount of time, and doesn't significantly interfere with enjoying and learning from the conference. Please note, that this role requires discipline and constant attention to all attendees. > > Information about hotel > Student Volunteer rooms are booked at (to be announced). If you are a student volunteer, do not book yourself, we have arranged the booking already! > > > > > > > > > > StÃ©phane Ducasse > http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> > 06 30 93 66 73 > > "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes StÃ©phane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73 "If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.â Calvin & Hobbes

March 18, 2025

Re: "Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Noury Bouraqadi

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 < koen(a)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

March 14, 2025

"Introducing Hera: Gherkin-style tests" â New blog post on all: objects all: theTime

by Koen De Hondt

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

March 9, 2025