A project implementation of the Scaffold framework, running in parallel against SauceDemo
This code is provided on an "AS-IS” basis without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement. Your tests and testing environments may require you to modify this framework. Issues regarding this framework should be submitted through GitHub. For questions regarding Sauce Labs integration, please see the Sauce Labs documentation at https://wiki.saucelabs.com/. This framework is not maintained by Sauce Labs Support.
To view the most current version of Scaffold, visit the Central Repository.
For a quick start on creating a new Scaffold project, check out the Scaffold-Archetype codebase.
For more in depth documentation regarding Scaffold, check out the Scaffold codebase.
- Java 11
- Maven 3.x
There are two potential methods of running the testing locally. The first is maven goal execution and the second is running the testing through the IDE. There are two pre reqs:
If you don't already have one, create a file named application.OVERRIDES in environment > src > main > resources > application-OVERRIDES.properties. In this file, include the desired capabilities and any other secret values required to run your testing.
NOTE: Make sure application.OVERRIDES is in your .gitignore
To run these tests locally, you will need Chrome and chromedriver installed and on your PATH. If you plan on using a different browser, install that local driver instead.
During your maven goal execution step on your CI, specify the following system property: -Dspring.profiles.active=your_spring_profile.properties.
This will pull the environment variables from the profile specified in the system property. For example, if you wanted to run the sauce chrome profile,
you'd enter the following command: mvn test -Dspring.profiles.active=overrides.properties
Create a new JUNIT run configuration for the testing you'd like to run locally. In the new run configuration, add the new environment variable spring.profiles.active=overrides. This setting will pull in the environment variables from the overrides profile when that test is run through the IDE.
Just like running the testing through maven locally, add a maven step in your CI testing pipeline that includes the spring profile you'd like to use.-Dspring.profiles.active=your_spring_profile.properties.
For example: mvn test -Dspring.profiles.active=sauce_chrome.properties
To run these tests on Sauce Labs, you will need to set two environment variables to match your Sauce Labs credentials.
You will need both your User Name and your Access Key:
Your user name is listed in blue at the top of the "My Account" page on the Sauce Labs site. Note that you need this username, not your full email address, in order to set the credentials properly.
To get your Access Key, go to the "My Account" page on the Sauce Labs site, and look below the graphs on the bottom half of the page. Your Access Key will be shown there, and you can click the clipboard icon to copy it.
Scaffold very strongly encourages use of a Page Object Model. Though it is not required, the Model greatly simplifies the abstractions you must write and maintain in order to keep your tests simple and user-focused. See Martin Fowler's seminal article about Page Objects for more detail.
Scaffold makes available particular types of WebElements for you to use, which narrow the scope of methods available for any given WebElement, and keep the user focused on the actions they should be performing on these elements. For example, You can't, as a user "sendKeys" to a Button or a Link. The ButtonWebElement and LinkWebElement objects take that account and don't expose those methods.
Another advantage of these elements is that they manage all interaction with the WebDriver internally. Most frameworks require the test write/page object maintainer to use the WebDriver to perform all their actions, which requires a lot of Selenium knowledge, and can also lead to race conditions, thread-safety issues, and the exposure of unnecessary complexity to the testers.
In the millions of test cases run by Scaffold over the years, there has never been a reported occurrence of a StaleElementReferenceException. This is possible because the framework manages the WebDriver and the WebElements internally, in a thread-safe and careful manner.
As a test-writer, you should never have to know about or interact with any instance of a WebDriver