Thanks Jonny, I was hoping you would have feedback😃. I appreciate the response and hopefully this is something that can be checked in / provided in the future.
Regards, James On Mon, Apr 13, 2026 at 6:12 PM Jonny <[email protected]> wrote: > Pardon the multiple messages, but I went ahead and just opened a PR. > https://github.com/apache/groovy-geb/pull/323 > > Comments welcome! > > On Mon, Apr 13, 2026 at 4:53 PM Jonny <[email protected]> wrote: > >> Also, to James's idea of publishing the skill on skills.sh, it looks like >> the Apache Beam folks put their skills in a .agent/skills directory within >> their repository: >> https://github.com/apache/beam/tree/master/.agent/skills. Perhaps we >> could do the same in Groovy and Geb? >> >> I know the Spock maintainers have also claimed space on Context7 ( >> https://github.com/spockframework/spock/commit/6eafb3de4c4042c789d2f508c42808d0b15e38ef >> ). >> >> On Mon, Apr 13, 2026 at 4:48 PM Jonny <[email protected]> wrote: >> >>> I added a few more tips that I've picked up over the years. >>> https://gist.github.com/jonnybot0/dcb7fb817ae6c1860eaec164391b49b7 >>> >>> Most are additions (ways to make your test not flaky, link to the Geb >>> docs), but there is one place that I pushed back hard against James's >>> clanker: >>> >>> > *Overusing required: false* on optional content - the only time you >>> really want to mark a page element as required: false is when your spec >>> *needs* to try to interact with it when it's absent (for example, to >>> assert that it isn't present, !page.buttons.sometimesThereButton). If >>> the button may or may not be there, but you never test the case where it >>> isn't there, you should just leave it as required. Remember, throwing an >>> exception when something *exceptional* happens is okay, especially in >>> tests! >>> >>> This was something that was drilled into me by Marcin, the former >>> maintainer of Geb *and* hard experience. I saw more than one case where >>> someone added `required: false` as a way to address flakiness in a test >>> that only *hid* the flakiness and moved it downstream. And that someone >>> was, often enough, me. AIs are even more prone to this kind of quick-fix, >>> unhelpfully-defensive thinking, so it's probably best if we ward them off >>> it out the gate. >>> >>> Best, >>> >>> Jonny >>> >>> On Mon, Apr 13, 2026 at 11:08 AM James Daugherty via dev < >>> [email protected]> wrote: >>> >>>> This was generated by an AI, but it is probably a good starting point: >>>> https://gist.github.com/jdaugherty/f63781ff72c826b14f20fc3a2a41020e >>>> If anyone has feedback, it would be most welcome. >>>> >>>> I know that some people are using services like https://skills.sh/ to >>>> index skills. Creating a dedicated repo for skills may be useful for >>>> Groovy / Geb. >>>> >>>> -James >>>> >>>> On Mon, Apr 13, 2026 at 8:00 AM Jochen Theodorou <[email protected]> >>>> wrote: >>>> > >>>> > On 4/12/26 19:44, James Daugherty via dev wrote: >>>> > > Hi Everyone, >>>> > > >>>> > > The Grails project has been gradually expanding its Geb test >>>> coverage >>>> > > and as we've reviewed the old tests / improved on them, it's become >>>> > > clear there are some best practices with Geb that we didn't always >>>> > > follow. This got me thinking: in the age of AI, the Grails team has >>>> > > discussed including AI skills (https://agentskills.io/home) as >>>> part of >>>> > > our development process to better help adoption. Has such a topic >>>> > > been discussed for Geb? Does anyone have a good starting skill for >>>> > > Geb? >>>> > Not me, but I would say to just write something and then let other >>>> > people look over it to improve it. >>>> > >>>> > bye Jochen >>>> >>>
