Maybe add some bonus features?

[rkeeves]

Hi Roland!

Nice repo! I just wanted to bring up three possible 'bonus' features.
Unfortunately these might be outside the scope of the repository.

Maybe add DI and hooks?

Probably for simplifaction reasons (aka students won't get overwhelmed) the reference to the WebDriver instance is owned and managed by AbstractStepDefs.

AbstractStepDefs is both:

• a global state (via protected homePage)
• a lifecycle callback (static init block is essentially acting as an onStart method)

If the need arises for a more robust solution, one could try:

• introducing a DI container, example of setting up a minimal DI container.
• using hooks for lifecycle events, example

But I understand that this might be too much 'technical noise', and might take away the student's attention from the real point and make the code more complex.

Maybe show Selenium alternatives?

Vanilla Selenium (no experimental Bidirectional API) is http:

test    request to browser
browser response to test
test    request to browser
browser response to test
...ad infinitum

Aka you cannot do websocketry like:

test    'Hey browser, when something happens call me back'
browser 'ok'
...time passes
browser 'Hey test, something happened'

With Playwright/cypress you can do it.
Unfortunately cypress is js only, but Playwright has a Java library.

It offers:

• autowaiting: you'll encounter radically less 'omg it simply clicked too fast' moments
• contexts: you have one browser, but each test gets an indepenent clean context
• network: capture requests/responses, assert on them, stub them, modify them etc.
• trace: you get trace out of the box.

I think trace is so visually appealing that it might be able to capture the attention of even 'zoned out/disinterested' students, so they get more involved.
(cypress has an even more involved 'visual feedback' mechanism)

All of these things (even websocketry) can be done by Selenium, but we have to write it ourselves...
I mean you can technically do CDP with selenium, but it won't be pretty.

In Java, interacting with Playwright is almost like Selenium (e.g. I have a repo which uses both Selenium and Playwright).

Maybe examples for lower level test design?

I think students might be interested in lower level test design examples too (I certainly am).

For instance the swag labs app under test has a stateful little thing called ShoppingCart. It is simple enough to understand quickly, but complex enough to be at least a bit interesting.

There are some ShoppingCart tests for it.

The tests use a pretty straightforward approach (examples of mostly happy things going happily).

It would be really-really cool to see how the earlier parts of the course can be applied, like truth table like tabulation, equivalence classes, state machines etc.

I also wanted to bring up this paper which might be interesting to you.
It combines a set of axioms and operations, thereby creating algebras, but with programming related objects not just mathematical things (like rings, groups etc.).
It starts off with a simple spec for a stack (eg. pop, push) so it is easy grasp how the math and the code 'connects together'.

Such algebras could be exist for other things too, like... ShoppingCarts.
So...in theory...even if we had some 'complicated' stateful code like ShoppingCart,
we could attempt to disprove that the implementation upholds 'axioms' of the theoretical model.

But leaving out JSON.parse, abstracting away local storage and other things. I mean if you override the localstorage with 1 then the code will be able to parse 1, and later when you add an item it'll call 1.push.'

[RolandMajor]

Hello!

Thanks for the feedback! I'm very glad to hear you're still interested in this topic. These are great suggestions!

Maybe add DI and hooks?

Getting rid of the static initialization and adding a DI container was actually one of the exercises planned for the class, after the initial example was understood. You've read my mind with this one.

Maybe show Selenium alternatives?

I've been meaning to look into Playwright for some time now, but sadly that time has not come yet. Using alternatives to vanilla Selenium is definitely in the backlog for the class though. If you have more suggestions that could be interesting, and easy enough for an introductory class, I'd love to hear them! The sky is the limit! (as long as the sky fits into 4*60 minutes per semester)

Maybe examples for lower level test design?

You're right, this would be interesting to add to the class. I have not thought of it before, but I will think about it now.
The paper you brought up certainly piqued my interest!