Transcripted Summary
Congrats! You've made it to the end of the course. 🎉
I intentionally opted not to teach you Java from the perspective of test automation, because that's limiting. I taught you Java in general and with this new skill, now you can do any programming that you desire including test automation.
Since this is a course on Test Automation University, I want to show you how prepared you are, even though we didn't explicitly work on test automation problems.
In this chapter, I'm going to show you a real test automation project that uses Selenium WebDriver, but please note that you can use your new skills with other automation libraries as well, including ones for mobile, API automation, or back-end automation.
In this chapter, I'll highlight how we use the concepts taught in this course in the context of test automation.
Here is a test automation project — I want to show you the packages here.
NOTE: This automation project can be found on GitHub.
Notice we have lots of packages this time; lots of different classes in here and this is typical of a test automation project. You've learned all about packages. You've learned about classes, so you know how they relate to one another.
Let's take a look at one of the classes — this one is a class called BaseTests.
This looks familiar to us — how you define classes.
We see on lines 12-13, even though we don't know what these objects are, we do know that these are global objects.
We know what the private and protected, and the static mean for these objects.
This particular one, on line 12, is a WebDriver object. You'll become very familiar with that once you learn about Selenium WebDriver. There are multiple courses on Test Automation University to teach you this.
This Page class is one that we created within our framework.
Let’s take a look at this one.
We have our class declaration, nothing new there.
You see there's also some fields on lines 15-18. One is protected, the rest of these are private fields.
These fields are locators, which you'll also learn about when you learn Selenium WebDriver or there's also a Web Element Locator Strategy course taught by Andrew Knight here on Test Automation University.
We see on line 20, there’s a constructor. This is using the this call to set the webDriver. We've learned all about this.
Then, we see some methods here.
This Page is a generic page that's holding all of the elements of that page as fields and then methods to interact with that page, like clicking on things within it.
This is known as the Page Object Model design pattern, which you'll learn more about in other courses as well, but I hope this doesn't look foreign to you.
We see things like return statements. We also see objects as return types.
Let's go back to BaseTests and look at this a little bit more — we see calls to methods.
We know that launchApplication() is a method. We see instantiation of some new objects.
We see this Links.HOME which tells us HOME must be a static constant variable.
We look at that, yep, that's exactly what it is,because we're using that convention of all uppercase to name the variable.
We see decision structures here in our test automation code.
Using an if-else statement to determine if we're on Windows or not. We use these branches to and we set a property in different ways.
This is a good use of decision structures within your test automation code.
Let's look at an actual test class, so we'll look at this SearchTest.
We see that this class is extending BaseTests, which means it's inheriting from that class.
We see the use of a typical variable. In test automation we can use variables for things that we're testing, so here we’ve created a String variable called productName and initialized it to "Apple TV."
Then, we use some object called homePage to call a method, search, and pass in that productName.
Where did this homePage come from? I don't see it defined anywhere in this class. Well, that must mean that we inherited it from BaseTests so it must exist there. Sure enough, there it is.
We see these assert methods, which are a part of JUnit, which will allow us to determine if a test has passed or not.
It's just a call to a method. We're just passing in some data.
We're calling some methods here.
This first line is saying, is the product listed in the search results? And searchResults is an object.
Let's look in SearchResults.
This SearchResults class, again, we see private fields. We see public methods. We know about this - encapsulation.
We see constructors. All of this is stuff that we've learned about.
We see here the use of a List.
We're getting all of the listed products from a page within our application. That's a good use of a List within test automation.
We see here, an enhanced for loop, to loop over all of those products to actually find the product that we're looking for.
We see another decision structure (if) to say, "Okay, as we're looping through all of the products that are listed here, does the current one that we're on equal the product name that we're looking for?". If so, return that object.
And we see the use of the equals() method we talked about.
Let's look at another Page class — this is a CartPage.
This is representing the shopping cart page within some application.
It's inheriting from Page — because remember Page is representative of any page within an app. It's a superclass to all other pages.
We see here, some fields. We see constructor.
Ah-ha! Look at the call to the super constructor. We already know that this is going to make a call into the Page constructor which takes a WebDriver.
This is all stuff that we've learned.
Then, we see another decision structure, so in case of this, it will throw a new exception.
We've just learned about exceptions in the last chapter, and we see how that's used in test automation.
# Applying What You’ve Learned
The idea here is that you know enough to move forward in test automation, should that be your journey. Everything that you've learned in this course is applicable to test automation.
Sure, there will be more that you need to learn, such as Selenium WebDriver, if you're going to be doing UI automation. Or we have an API test automation course as well as a REST Assured course on Test Automation U, if you're going to be doing API testing.
Whatever you'd like to do, now you have the foundation to move forward.
It's been my absolute pleasure to share this course with you! It has definitely been a labor of love ❤️. I hope that you're better for it. Take care. 🙏🏾
Optional Independent Exercise
I have one final exercise for you. Consider it as a final project. It's exercising a lot of the things that we've learned throughout this course. Of course, it's optional, but I strongly encourage you to do it.
You're going to create an object-oriented coin toss game — this project will consist of three classes.
The first class is Coin.
It should contain a field called side, encapsulation, constant variables for heads and tails, a method called flip(), which randomly chooses heads or tails and assigns that value to side.
Your second class will be one called Player.
This one will have fields called name and guess.
You'll also have encapsulation in Player, and then add a constructor which accepts a player's name.
Finally, the third class will be one called CoinTossGame — which creates two players.
It asks player 1 to choose heads or tails, and ensures that player 1’s guess is valid.
Don't move on until player 1 actually has a valid guess.
Then, automatically assign player 2’s guess to the opposite of what player 1 chose.
You're going to flip the coin in this class to determine which side it landed on. Then you're going to determine a winner based on what the coin landed on.
Also, be sure to use methods appropriately in this class.
Give it a go.
Solution
Programming can be done many different ways, but here’s my solution.
