Back To Basics - How does WebDriver driver = new FirefoxDriver(); work?
Have you ever thought how this line works?
WebDriver driver = new FirefoxDriver();
More specifically, why are 2 types needed for creating the driver object?
And why is it possible to create a WebDriver variable but instantiate it with a FirefoxDriver object?
You can find the answer here.
Want Success In Your Testing Career? Follow Iceland's Soccer Strategy
This is not an article about soccer.
It just uses soccer as a pretext.
Because good ideas are everywhere.
The European Soccer Championship is taking place these days.
It is in the quarterfinals phase with just 8 teams left:
Iceland, in quarterfinals?
One of them is a big surprise: Iceland.
To get to quarterfinals, Iceland had 2 draws and 2 wins:
Iceland - Portugal 1 - 1
Iceland - Hungary 1 - 1
Iceland - Austria 2 - 1
Iceland - England 2 - 1
Iceland's opponents have the following populations:
Portugal - 10.4 million
Hungary - 9.8 million
Austria - 8.4 million
England - 53 million
Iceland is one of the smallest countries in Europe with just above 300.000 people.
Soccer is popular in Iceland and was never too good.
It is a great achievement for the Iceland soccer team to qualify to the European Soccer Championship.
To reach the quarterfinals of the championship is just incredible.
How did Iceland do it?
Was it a fluke, an accident, a stroke of luck?
Iceland beat England because his players were more motivated, had better execution and more desire.
But there is something else that explains the Iceland's success.
With such a low population, Iceland has a limited pool of players.
It has to do well with the players it has.
And that's what they did.
Iceland invested heavily in soccer
So they invested in training and more training.
Iceland took TV money from UEFA (Union of European Association) and invested it all in infrastructure, coaching and player development.
They build heated indoor fields all over the country (Iceland has very low temperature throughout the year and lots of snow) and helped hundreds of coaches get UEFA licenses.
There are so many UEFA licenses soccer coaches in Iceland that they have one for every 825 people.
Compare this with 1 for every 11.000 people in England.
There was no fluke in Iceland making it to the quarterfinal of the European championship.
The big investment in soccer paid out big time.
Iceland no longer has a small soccer team in Europe but an important one.
And your point is, Alex?
As a tester or IT professional, if you want to have success in your career, you need to invest first.
Not in a house or in stocks.
Invest in yourself
Invest time, energy and money in your training.
Invest in growing your knowledge, your skills, your communication.
Expand your skills.
If you are a manual tester, learn programming and test automation.
If you know test automation, learn performance testing.
If you know performance testing, learn API testing.
Your knowledge and skills will mature as a result of the investment.
And the success will come shortly.
It just uses soccer as a pretext.
Because good ideas are everywhere.
The European Soccer Championship is taking place these days.
It is in the quarterfinals phase with just 8 teams left:
- Poland - Portugal
- Wales - Belgium
- Germany - Italy
- France - Iceland
Iceland, in quarterfinals?
One of them is a big surprise: Iceland.
To get to quarterfinals, Iceland had 2 draws and 2 wins:
Iceland - Portugal 1 - 1
Iceland - Hungary 1 - 1
Iceland - Austria 2 - 1
Iceland - England 2 - 1
Iceland's opponents have the following populations:
Portugal - 10.4 million
Hungary - 9.8 million
Austria - 8.4 million
England - 53 million
Iceland is one of the smallest countries in Europe with just above 300.000 people.
Soccer is popular in Iceland and was never too good.
It is a great achievement for the Iceland soccer team to qualify to the European Soccer Championship.
To reach the quarterfinals of the championship is just incredible.
How did Iceland do it?
Was it a fluke, an accident, a stroke of luck?
Iceland beat England because his players were more motivated, had better execution and more desire.
But there is something else that explains the Iceland's success.
With such a low population, Iceland has a limited pool of players.
It has to do well with the players it has.
And that's what they did.
Iceland invested heavily in soccer
So they invested in training and more training.
Iceland took TV money from UEFA (Union of European Association) and invested it all in infrastructure, coaching and player development.
They build heated indoor fields all over the country (Iceland has very low temperature throughout the year and lots of snow) and helped hundreds of coaches get UEFA licenses.
There are so many UEFA licenses soccer coaches in Iceland that they have one for every 825 people.
Compare this with 1 for every 11.000 people in England.
There was no fluke in Iceland making it to the quarterfinal of the European championship.
The big investment in soccer paid out big time.
Iceland no longer has a small soccer team in Europe but an important one.
And your point is, Alex?
As a tester or IT professional, if you want to have success in your career, you need to invest first.
Not in a house or in stocks.
Invest in yourself
Invest time, energy and money in your training.
Invest in growing your knowledge, your skills, your communication.
Expand your skills.
If you are a manual tester, learn programming and test automation.
If you know test automation, learn performance testing.
If you know performance testing, learn API testing.
Your knowledge and skills will mature as a result of the investment.
And the success will come shortly.
Shortcuts and Tips for Test Automation Beginners
Euclid, the inventor of geometry, was asked once by the ruler of Greece if there is a shorter road for learning geometry.
There is no royal road to geometry, Euclid replied.
There are no shortcuts to test automation with Selenium.
Tips are easier to give.
So, before starting test automation,
- learn the programming language well
- learn how to write clean code with your programming language
Learn Page Objects in 3 Easy Lessons
How does your test automation code look like?
Does it look like this?
driver.get(homePageUrl);
WebElement searchTextBox = browserDriver.findElement(By.id(searchTextBoxId));
searchTextBox.click();
searchTextBox.clear();
searchTextBox.sendKeys(keyword);
WebElement searchTextButton = driver.findElement(By.id(searchTextButtonLocator));
searchTextButton.click();
assertTrue(driver.getTitle().equalsIgnoreCase(expectedResultsPageTitle));
assertTrue(driver.getCurrentUrl().equalsIgnoreCase(expectedResultsPageUrl));
WebElement resultCountLabel = browserDriver.findElement(By.xpath(resultCountLocator);
String resultCountText = resultCountLabel.getText();
int startIndex = resultCountText.substring("of") + 3;
int endIndex = resultCountText.substring(" items");
int resultCount = Integer.parseInt(resultCountText.substring(startIndex, endIndex);
assertTrue(resultCount > 0);
or this?
HomePage homePage = new HomePage(driver);
homePage.openPage();
homePage.searchForKeyword("java");
ResultsPage resultsPage = new ResultsPage(driver);
assertTrue(resultsPage.isOpen() == true);
assertTrue(resultsPage.resultCount() > 0);
If you can write the first version and want to modify it into the second, this step-by-step tutorial is for you.
The tutorial shows you everything you need to know for creating page objects.
The tutorial has 3 parts:
1. how to create page objects
2. how to create page elements
3. how to use page factory
When learning to create page objects, we will go through the following iterations:
1. PREPARE THE TEST CASE FOR AUTOMATION
1.1 group test case actions by page
1.2 break down test case actions in sub-actions
1.3 create methods and variables for each action and sub-action
2. CREATE THE TEST CLASS
2.1 Component of a test class
2.2 How a test script is executed
2.3 Create the template of the test class
2.4 Add code for setUpEnvironment() and cleanUpEnvironment() methods
2.5 Add the code for the test script
2.6 Create objects for the homePage and resultsPage
3. CREATE THE HOME PAGE CLASS
3.1 Create the template of the home page
3.2 Add the fields and methods to the class
3.3 Add values to the fields of the class
3.4 Add the WebDriver field and constructor to the class
3.5 Add the code for the methods
4. CREATE THE RESULTS PAGE CLASS
4.1 Create the template of the results page
4.2 Add the fields and methods to the class
4.3 Add values to the fields of the class
4.4 Add the WebDriver field and constructor to the class
4.5 Add the code for the methods
Want to get started?
Transfer USD 25 through Paypal to alex@alexsiminiuc.com today.
You get the 3-part tutorial and unlimited email support.
Have too Many Assertions in Test Scripts? Use Custom Assertions Instead
If your JUNIT test script uses too many assertions, you can reduce their number with
- custom assertions and
- test objects
Having less assertions in the test script makes the script shorter, easier to read and maintain.
These are things that need to be done on all code, both for application and tests.
Lets start with an example
The following code sample tests that multiple user variables (firstName, lastName, age, address, city, country) have the correct values.
The user variables' values are provided by utility methods (getFirstName(), getLastName(), getAge(), getAddress(), getCity()).
The test script works but it is too long and complicated for the simple thing that it implements.
Let's assume that it is possible to get a User object instead of getting firstName, lastName, age, address and city separately.
The user object is provided by a utility method called getUser().
It returns an object of a User class:
The following code sample tests that multiple user variables (firstName, lastName, age, address, city, country) have the correct values.
import static org.junit.Assert.*;import org.junit.Test;
public class AssertionTests {
private String generateFirstName() { return "John"; }private String generateLastName() { return "Smith"; }
private int generateAge() { return 32; }
private String generateAddress() { return "123 main street"; }
private String generateCity() { return "Burnaby"; }
private String generateCountry() { return "USA"; }
@Testpublic void testUserDetailsWithMultipleAssertions(){
String firstName = getFirstName();
String lastName = getLastName();
int age = getAge();
String address = getAddress();
String city = getCity();
String country = getCountry();
assertTrue("firstname is incorrect", firstName.equalsIgnoreCase("John"));
assertTrue("lastname is incorrect", lastName.equalsIgnoreCase("Smith"));
assertEquals("age is incorrect", age, 32);
assertTrue("address is incorrect", address.equalsIgnoreCase("123 main street"));
assertTrue("city is incorrect", city.equalsIgnoreCase("Burnaby"));
assertTrue("country is incorrect", country.equalsIgnoreCase("USA"));}
The user variables' values are provided by utility methods (getFirstName(), getLastName(), getAge(), getAddress(), getCity()).
The test script works but it is too long and complicated for the simple thing that it implements.
Let's assume that it is possible to get a User object instead of getting firstName, lastName, age, address and city separately.
The user object is provided by a utility method called getUser().
It returns an object of a User class:
public class User {
private String firstName;
private String lastName;
private int age;
private String address;
private String city;
private String country;
public User(String firstName, String lastName, int age,
String address, String city, String country)
{
this.firstName = firstName;
this.lastName = lastName;
this.age = age;
this.address = address;
this.city = city;
this.country = country;
}
public String firstName() {
return this.firstName;
}
public String lastName() {
return this.lastName;
}
public int age() {
return this.age;
}
public String address() {
return this.address;
}
public String city() {
return this.city;
}
public String country() {
return this.country;
}
}The User class is very simple:
- The constructor has parameters for firstName, lastName, age, address and city and saves them in the class's fields
- The class has get methods for its fields
Having the User class, we can use an object in the test script instead of separate variables:
import static org.junit.Assert.*;
import org.junit.Test;
public class AssertionTests {
private User getUser()
{
return new User("John", "Smith", 32, "123 main street", "Burnaby", "USA"
}
@Test
public void testUserDetailsWithMultipleAssertions()
{
User user = getUser();
assertTrue("firstname is incorrect",
user.firstName().equalsIgnoreCase("John"));
assertTrue("lastname is incorrect",
user.lastName().equalsIgnoreCase("Smith"));
assertEquals("age is incorrect",
user.age(), 32);
assertTrue("address is incorrect",
user.address().equalsIgnoreCase("123 main street"));
assertTrue("city is incorrect",
user.city().equalsIgnoreCase("Burnaby"));
assertTrue("country is incorrect",
user.country().equalsIgnoreCase("USA"));
}
}
The test script looks a bit better when using the user object but it is still too long.
Create a custom assertion
The first way of simplifying the test script is with a custom assertion method.
Since we are using the user object, we can pass it to the custom assertion who will just include the individual assertions:
import static org.junit.Assert.*;
import org.junit.Test;
public class AssertionTests {
private void assertCorrectUserDetails(User user)
{
assertTrue("firstname is incorrect",
user.firstName().equalsIgnoreCase("John"));
assertTrue("lastname is incorrect",
user.lastName().equalsIgnoreCase("Smith"));
assertEquals("age is incorrect", user.age(), 32);
assertTrue("address is incorrect",
user.address().equalsIgnoreCase("123 main street"));
assertTrue("city is incorrect",
user.city().equalsIgnoreCase("Burnaby"));
assertTrue("country is incorrect",
user.country().equalsIgnoreCase("USA"));
}
private User getUser()
{
return new User("John", "Smith", 32, "123 main street", "Burnaby", "USA");
}
@Test
public void testUserDetailsWithCustomAssertion()
{
User user = getUser();
assertCorrectUserDetails(user);
}
}
The test script is very short when using the user object and a custom assertion.
But it lacks clarity since there is data hard-coded in the assertions that make the custom assertion.
We can remove the hard-coded data by creating a test object that uses the User class as well.
Then, we compare the user object with the test object in an assertion.
Compare the user object with a test user object
First, we will add a new method to the User class that compares 2 user objects:
public Boolean equalsTo(User anotherUser)
{
Boolean result = false;
if (
this.firstName().equalsIgnoreCase(anotherUser.firstName()) &&
this.lastName().equalsIgnoreCase(anotherUser.lastName()) &&
this.age() == anotherUser.age() &&
this.address().equalsIgnoreCase(anotherUser.address()) &&
this.city().equalsIgnoreCase(anotherUser.city()) &&
this.country().equalsIgnoreCase(anotherUser.country())
)
result = true;
return result;
}
The method is quite simple.
It gets a User object as parameter and compares the parameter's fields with the currect object's fields.
If all fields are equal, it returns true, otherwise false.
The test script gets its final version now:
@Test
public void testCorrectUser()
{
User user = getUser();
User testUser = new User("John", "Smith", 32, "123 main street", "Burnaby", "USA");
assertTrue(user.equalsTo(testUser) == true);
}
It first gets the user object.
Then, it creates a testUser object.
Finally, it asserts that the 2 objects are equal using the equalsTo() method of the User class.
What is the market demand for manual testers compared to automation testers?
First, each country's job market is different.
There are trends that apply to all countries but there are significant differences as well.
Second, no one has the complete information on all jobs available on a market.
Not even the IT recruiters.
Everyone has access to a piece or a few pieces of the job market puzzle.
The whole puzzle is impossible to see.
Instead of an answer, I have for you a few hints, hopefully useful.
1. Many Test Automation Positions Available, Few Suitable Candidates
Every time I talk to recruiters about market demand, I hear that companies need badly manual testers with good automation skills.
These testers should know manual testing, have technical skills, know good programming and good test automation.
The programming and test automation skills are required by companies that already do automation but also by companies that dont have automation yet.
Because if a company does not have automation yet, it is either getting ready for starting it or thinking about doing automation in the near future.
So recruiters have these days many open opportunities for testers that have programming and test automation skills.
And in many cases, they cannot find suitable candidates for them.
Because not many manual testers have good programming skills.
Because not many manual testers have good programming skills.
On the other hand, there are just a handful of "pure" manual testing positions available, from time to time.
2. Job Trends: more automation jobs, less functional testing jobs
The indeed.com site can display the job trends for a specific keyword during a time interval.
Let's see how the indeed.com trends for functional testing and quality assurance look like.
The functional testing trend between 2012 - 2016 is descending.
The functional testing trend between 2012 - 2016 is descending.
3. Testing Trends: developer and tester roles will merge, more test automation needed
Take for example this survey:
It says that
The increasing adoption of DevOps principle is expected to break the silos of roles divided in terms of activities between developers, QA/testers, business analysts and production manager.
We know, with changing times, the developers and operation managers have started adopting testing activity as a part of their day-to-day job.
In fact, they love to test to ensure the defects do not get carried forward in the production lifecycle.
Thus, keeping this trend in mind, the experts predict that, the roles of developers and testers will merge in the years to come.
and also that
... chances are that there would be more collaboration among developers, IT professionals and operation engineers leading to increasing adoption of DevOps.
With more and more enterprises merging the roles of testers with developers and operational engineers due to overlapping competencies and the need to fit in the continuous agile cycles,
DevOps methodology will be the most In-Thing in the year 2016.
As per Google Trends, 67% enterprises engage in DevOps principle to tap the benefits of cross-functional skills and speed up the test project deliveries.
Similar predictions are being made by Gallop:
Test automation in the age of DevOps
The level of Test Automation is one of the key indicators of a testing organization’s efficiency.
Test automation adoption is going to grow at a rapid pace this year as organizations looks at delivering bug-free, high-quality software.
4. Google Search: more test automation searches
Google trends provide details regarding how many searches for a specific topic happen in a time interval.
They show similar patterns with the indeed.com trends.
The trend for Selenium searches is ascending.
So what do all these mean? Is the market demand higher for manual testing or automation?
Instead of a conclusion, how about another question?
Which one do you think is higher?
The market demand for manual testers?
The market demand for automation testers?
Or the market demand for manual testers that know automation?
Run Test Automation Scripts in Command Prompt with Maven
While developing the Selenium WebDriver test automation scripts, the scripts are executed within Eclipse.
But as soon as the scripts work as expected, you may want to make the scripts available to other team members.
Like other manual testers.
Or developers.
You may also want to run the test scripts automatically as scheduled jobs.
Or use them in a continuous integration process.
All these require the ability of running the test scripts in the Command Prompt.
Subscribe to:
Posts (Atom)















