[junit5] implement this library with extension instead of superclass

[titusfortner]

I still need to tidy up the examples, but I want to show off status. Registering an extension instead of a super class is going to be significantly more flexible for toggling between local and remote, etc.

Update: See updated code in comment below:
Updated Update: I've re-instated original behavior and removed the builder pattern: See most recent comment

Here is the minimal implementation:

@RegisterExtension static SauceBindingsExtension sauceExtension = new SauceBindingsExtension();

@Test
public void createSession() {
  sauceExtension.getSession().annotate("Running a test here");
  sauceExtension.getDriver().get("https://www.saucedemo.com/");
}

Tweaking options/data center before startup goes into the extension constructor:

static SauceBindingsExtension sauceExtension =
  new SauceBindingsExtension(getSauceOptions(), DataCenter.US_WEST);

or

static SauceBindingsExtension sauceExtension =
   new SauceBindingsExtension(getCapabilities(), DataCenter.US_WEST);

So existing users just need to move their capability generation out of their before hook, into a static method and then pass it into the extension constructor.

[titusfortner]

Ok, because I want to allow setting:

1. Capabilities
2. SauceOptions
3. DataCenter
4. Enabled/Disalbed

It does not make sense to do this all as a bunch of different constructors, so it is now set to use a Build pattern. Which, I don't love, but. makes the most sense here.

This example shows off everything:
https://github.com/saucelabs/sauce_bindings/blob/3eed57e462bd1e0b094678fe3248dfa10ea7e2ff/java/junit5/src/test/java/com/saucelabs/saucebindings/junit5/examples/LocalExample.java

1. Register multiple extensions (you can see there is access to the driver object in LocalTestWatcher even when used with SauceBindingsExtension
2. Toggles whether SauceBindingsExtension is enabled based on System property (Boolean.getBoolean("sauce.enabled"))
3. This shows createSauceOptions() but could just as easily be createCapabilities()
4. It might be a little clunky to do this every time session information is needed:

    if (useSauce()) {
      session.annotate("Navigating to Swag Labs");
    }

Would it make actual sense to have a "dummy" SauceSession object that was just a noop for every method? 🤔

[nadvolod]

I really like it for the most part. Just a few tiny clarifications.

[titusfortner]

Updated again:

1. Enabled by default because that's what Registering an Extension should do
2. Disable by one of:
   • Set Environment Variable of "SAUCE_DISABLED" to "true"
   • Set System Property of "sauce.disabled" to "true"
   • Comment out the Registration line 😂
3. Back to Constructors instead of Builder Pattern because more straightforward
4. There's one chunk of code that we can remove when [java] allow map to include "sauce:options" #305 is merged/released

[titusfortner]

Hmm, not sure why local example isn't passing, since it should be exactly the same as disabled test. They work locally and that error indicates the driver and browser versions do not match. I'll turn on logging to see what's different.

[nadvolod]

@titusfortner you want me to merge this?

[titusfortner]

Let me figure out why it is failing the test first. 😦

[diemol]

Just some minor comments that we could address quickly.

Thank you, @titusfortner!

[titusfortner]

Our implementation of getenv() method checks both property and environment variable

[titusfortner]

oh, maybe that was something special in SauceBindings not this library