Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a demo code base using Scaffold #11

Open
kgress opened this issue Mar 22, 2019 · 4 comments
Open

Create a demo code base using Scaffold #11

kgress opened this issue Mar 22, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@kgress
Copy link
Contributor

kgress commented Mar 22, 2019

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
@kgress kgress added the enhancement New feature or request label Mar 22, 2019
@mmerrell-sauce
Copy link

Have a look at this link, and let me know what you think. It's not finished yet, but directionally I think it's headed in the right direction: https://github.com/saucelabs-sample-test-frameworks/Java-Scaffold-Selenium

@kgress
Copy link
Contributor Author

kgress commented May 9, 2019

I took a look at the codebase. It's looking pretty good. I think you're headed in the right direction and I have some small comments for improvements. Would you like to wait until after you complete it before diving into suggestions?

@mmerrell-sauce
Copy link

Nope, let's hear it... I don't have enough time to work on this consistently to think I can complete it soon. In-line comments would be great, or comments here. Your choice!

@kgress
Copy link
Contributor Author

kgress commented May 15, 2019

Since it's not a PR or comparison, I'm not able to add any in line comments on the source code. I'll include comments on this ticket. It's going to be a lengthy comment for this reason. Apologies for that.

BasePage
I like this idea. We used something like this with our internal iterations but this could be changed to a generic that takes a parameter of an extended type AbstractWebElement. It could perform the check of getWebElement().isDisplayed() in order to do the verification of the page. I like this a lot. Let's talk about getting this added into scaffold. The ticket for this work is already here.

LoginPage
I love that you're using lombok here.

  • Do you think @Setter is necessary here? Is there a time where we would want to set an element?
  • The default constructor isn't needed
  • The login function should be using the getters for the defined properties. I.E: getUsernameInput.sendKeys(username); instead of usernameInput.sendKeys(username);

InventoryPage
I like your interesting usage of creating a new strongly typed element in the getters that pertain to the index requested by the method parameter.

Looking at this code, I think there's opportunity to abstract findElement(...) in Scaffold a bit. We could add abstractions like ```public T findElementByClass(T elementType, String className) {}``. We could add additional abstractions for ID, CSS, etc.

SauceDemoNavigation
My only advice for this file is to refactor the name to Navigation only as a QOL upgrade. Simpler, and shorter.

BaseTest
I notice on here the setTestStatus() method. This is something that needs to get added to Scaffold. I have the ticket at this link here. We should get this added in sooner than later, I think.

application-CHROMELOCAL.properties
A couple comments here:

  • The environment-type is no longer required (and doesn't exist)
  • Local settings like this I think should live in the application-OVERRIDES.properties file. I don't see a use case where you'll want to run a ton of testing on your local machine. Unless, however, you have some sort of old school farm setup.

application-CHROMESAUCE.properties
We've talked a little bit about the sauce url in the past. I believe there are currently three different hubs that SauceLabs provide. Is that correct? If so, we could create an enum for the sauce url that pertains to each of those api endpoints as long as they are constant across all SauceLabs users.

applicationContext-test.xml
This looks like an older Spring artifact. From what it looks like, you're creating a new bean for environment.

The nice thing about spring boot is that you can create beans with method level annotation. You can see the doc on that here.

So in this case you can delete this file and add this bean to your SauceDemoConfig file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants