Bug

Any merge commit to master should trigger the deploy job. In this case, type = push is not triggering the build since we are doing merges.

Expected

Merges should trigger the build.

Summary

This ticket is for looking into a way we could verify a page is the correct page we're expecting prior to returning the page object. We could use a generic method under navigation that will check to ensure it's navigated to the right page prior to returning the new object. This could also relate somewhat to ticket #8 .

We could do this by checking for the page header, for example, on that new page. If it throws a NoSuchElementFoundException, we could try to do the navigation again. If failing for several times, throw an error that states the page could not be verified?

We don't want the page verification to be too obstructive so we will need to spend some time thinking about options.

A/C

• Investigate and POC a new method for page verification that is not too obstructive

Summary

In order for test results to appear as a pass/fail in Sauce, we need to implement the update_job method in the Sauce Labs REST API, as seen here.

A/C

• Scaffold should report a pass or a fail to the sauce labs API
• If a test cannot complete or stalls, we should report that as neither a pass or fail

Summary

There are several outdated lib versions in our pom. We should update everything to latest including, but not limited to:

• Spring boot
• jackson-databind

A/C

• Update pom with newer versions of libs

Summary:

We should create a new annotation that allows users implementing scaffold to have just one annotation instead of three on their BaseTest file.

E.G, on an implementing project "AutomationCodeBase" :

@Execution(ExecutionMode.CONCURRENT)
@ExtendWith(SpringExtension.class)
@SpringBootTest(
        webEnvironment = SpringBootTest.WebEnvironment.NONE,
        classes = { AutomationCodeBaseConfig.class, ScaffoldConfig.class }
)
public class BaseTest extends ScaffoldBaseTest { ... }

This is a bit heavy and having a single annotation that bubbles all of these configurations up would be helpful.

A/C:

• Create a new Spring annotation that includes the execution mode, the SpringExtension, and the SpringBootTest configuration annotations

Summary

We should manually do the initial push of artifacts out to the maven repo. This should be done only for this initial release. Any further pushes should be handled by a build.

A/C

• Push the artifacts

Summary

The SauceLabs Platform Configurator lists iOS as a platform. We should add this to the Platform enum to support iOS testing.

A/C

• Add iOS on the Platform enum

Bug

When the CI attempts to deploy artifacts, the gpg credentials don't work

gpg: no default secret key: bad passphrase
gpg: signing failed: bad passphrase

Expected

The gpg creds should work. The pipeline includes a settings file with the proper configuration.

Bug

CI does not have permissions to push to github repo.

Expected

Travis CI should have the access.

Summary

Somewhat related to #11 , we should create a Maven Archetype and push it to the maven repo. This will allow users to quickly and efficiently get started with a new project without having to worry about the organization and formatting of their codebase.

We should think about what exactly is going to be created with this archetype. Should we create an archetype that provides similar purpose to what the example code base does? In this case, having a runnable example from the moment you create the new project with the archetype. Or, should we only worry about the package structure and some default files like the application.properties file?

I think open discussion is warranted regarding what we would like to see with the archetype.

Questions/Concerns

• Should this archetype live with the Scaffold repo or should we create a new repo for this?
• What should we include in the archetype?

A/C

• Figure out what we'd like to see with the maven archetype
• Do the work!
• Update this A/C once the requirements have been figured out

there is a test for value.isBlank instead of !value.isBlank

Summary

The TestContextSetting interface contains a collection of constant values that are currently being used along with the BaseTestContext singleton for adding and getting settings to the WebDriverContext.

Over half of these are not being used:

• PROXY_MANAGER
• PROXY_ASSIGNER
• QUEUE_HOST
• QUEUE_NAME
• TEST_APPLICATION_CONTEXT

We should take a look and see if these values are required. Even further, we should determine if the TestContextSetting is necessary at all.

A/C

• Investigate whether or not the TestContextSetting interface is required
• After determination, commit changes and submit PR if a code change is required

Summary:

Currently, when a test fails due to an unexpected error on the UI, the test will fail in a couple of ways:

• NoSuchElementException
• WebDriverException

Instead of having these errors at the top level by default, we should first check to see if there are any errors displayed on the UI first and report those prior to reporting an element couldn't be found or if there's a problem with the WebDriver.

An example failure:

org.openqa.selenium.NoSuchElementException: no such element: Unable to locate element: {"method":"css selector","selector":"[data-qa='some-link']"}
  (Session info: chrome=71.0.3578.80)
  (Driver info: chromedriver=2.44.609538 (b655c5a60b0b544917107a59d4153d4bf78e1b90),platform=Windows NT 6.1.7601 SP1 x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 0 milliseconds
For documentation on this error, please visit: http://seleniumhq.org/exceptions/no_such_element.html
...

This error appeared during the Navigation class so we can assume that there is a problem with navigation; but, we don't know the exact reason why there was a problem with navigation. We must first look at the sauce labs dashboard to view the video from the test run. In this example above, we found that there was a problem with the UI and it displayed a generic error message; therefore, the element we were looking for could not be found.

Not being able to find an element on a page, as it's doing now, infers that the automation did not encounter any issues with the UI and that it simply wasn't able to find the element; which is not entirely the most truthful case.

As a bonus to this, if we could also report any errors in the console, this would help out tremendously for debugging purposes.

Risk/other

I'm not sure there's a one sized fits all solution for this. There are a lot of different potential cases for where we would like to see this kind of behavior.

One potential thing to consider is figuring out a way that we can generalize this to apply to multiple element types. Thankfully, the way our strongly typed elements are set up right now, they all inherit off of a parent class.

I think, in general, it is possible to just check the dom for any instances of an attribute on an element of "is-error". Maybe we can check the console?

A/C:

• Scaffold should be able to report UI level errors as a first level form of error reporting
• If there's no problems with the UI, Scaffold should report the next level down - e.g. NoSuchElementException or WebDriverException

Summary

We should create a codebase that demonstrates how to use Scaffold. This will be most helpful for new users and exist as the "model home" of how to implement.

This demo could base should provide a clear example of how to do all of the things, including but not limited to:

• Page Objects
• Navigation
• Spring configurations
• Browser configurations
• Test writing
• Gotchas
• (Optional) External service configurations
• Utilities

A/C

• The demo code base should be using Scaffold
• It should be testing a demo website that is public and will not damage the company's brand or integrity
• It should demonstrate how to create page objects
• It should demonstrate how to create navigation
• It should demonstrate how to configure Spring
• It should demonstrate how to configure the browser configurations
• It should demonstrate how to write a test

Summary

With separation of concerns in mind, we should move the navigate method from the WebDriverWrapper to the WebDriverNavigation method. Inherently, I think this makes the most sense as the WebDriverNavigation is supposed to be responsible only for anything navigation related.

    /**
     * Navigate to a specified URL
     *
     * @return as a {@link Navigation}
     */
    public Navigation navigate() {
        return this.driver.navigate();
    }

We should also think about moving anything else navigation related outside of the navigation method.

A/C

• Move the navigate method from the WebDriverWrapper to WebDriverNavigation
• Look into moving any other navigation related methods to WebDriverNavigation where it won't impede the ScaffoldBaseTest and any implementing BaseTest file from implementing projects

Bug

The script right now is always pushing a release.

Expected

We should only be releasing on a new conventional commit and always have the build run testing.

Summary

Currently, the AbstractWebElement class implements a Scaffold interface called BaseWebElement. Right now, this interface is supposed to be a clone of the WebElement, from Selenium, but uses our strongly typed elements. It also protects the codebase from any major changes to the Selenium API.

However, there are currently some features in the BaseWebElement that are missing from the WebElement interface. This ticket is to update this class and interface to accurately clone the WebElement. For example, the isSelected() method is not being used.

We should make the current public getWebElement() method private and either rename this method or the existing protected getWebElement method to give us a better idea on what is going on.

Also, keep in mind that we have an AbstractClickable class that is used by elements such as ButtonWebElement. We should still ensure that we're encapsulating actions for elements correctly.

A/C

• Scaffold's BaseWebElement should have all of the same functionality from WebElement provided
• Scaffold should still ensure proper encapsulation by providing methods like click() in the AbstractClickable class.
• We should rename the getWebElement() methods to accurately reflect the actions they are performing and also change their access accordingly.

Summary

Right now, we are using Junit Jupiter's @Test and @DisplayName on our test cases. We could wrap both of these annotation to a single @Test annotation on Scaffold so we can write the DisplayName of the test inline with @Test.

@DisplayName currently provides value in formatting the SauceLabs Dashboard test results with a String other than the test method name.

For example, a single @Test annotation that looks like this:

@Test("Clicking Go Should Do the Thing")
public void testGoButton() {
    insertLogicHere();
    assertion;
}

A/C

• Scaffold should provide an annotation that allows users to write an inline @DisplayName with the @Test annotation
• Scaffold should still allow users to use the base @Test annotation if they do not want to use @DisplayName

Summary

After our initial manual release of 1.0.0-beta artifacts, we need to create automated builds that will handle the release for us.

We won't be using the maven-release-plugin for this tool. @tklovett presented a pretty solid idea by just releasing with scm. These links are good references:

• https://axelfontaine.com/blog/final-nail.html
• https://axelfontaine.com/blog/dead-burried.html

For our CI tool, let's think about using gitlab. In this ticket, investigate the setup required for using it.

A/C

• Investigate gitlab CI
• Create a new build for maven releases

h1. Summary
Whenever a user interacts with Scaffold's strongly typed elements, e.g. a click() or getText(), it uses the AbstractWebElement's protected getWebElement(boolean throwExceptionIfNotFound) method.

While this method does provide some error handling from other methods that use it, it doesn't provide any additional clues for cases where an element wasn't found due to some potential issue with javascript or an unforeseen error that is provided by the browser console.

This ticket is to add console log reporting. As noted in issue #8 , here is a stack overflow article that goes into detail on how we can pull logs: https://stackoverflow.com/questions/25431380/capturing-browser-logs-with-selenium-webdriver-using-java.

We don't need to do anything too fancy right now. My thought behind this is that we can just let lombok report these errors as log.error when and if they exist during the protected getWebElement(boolean throwExceptionIfNotFound) catch block of a NoSuchElementException. Just this alone will enhance our error reporting for failed tests.

h1. A/C

• Scaffold should report console errors when an element is interacted with in such a way that produces an exception

Bug

When combining the maven goals to set the version and run the deploy, it's using the DEV (local) version for the deploy.

Expected

The maven goals should be separate steps. 'Twas working like this before.