Home

Project goal

Tutorial on how to start a selenium + testng + maven.
It highlights that by designing your end to end tests properly in the first place switching to grid + CI for scalability won't require any refactoring for QE. It also shows that designing your tests for grid doesn't require a huge amount of effort. It's something that can be done in a day.

Requirements :

• browser management shouldn't be a concern while writing the tests.Focus on business logic.
• the tests should run locally for debugging, remotely, or in Selenium Grid.
• but end to end tests are not web only. Tests suites always require some DB validation, API calls etc.
• no change needed either when running the tests from a CI.

All that is easy if you use testNG listeners and follow a couple of principles.

This project is demonstrating basic TestNG + Selenium integration. Writing good, low maintenance tests ( PageObject design ), and more complex integration in a complex QA environment are not covered.

Underlying assumptions

Tests are isolated.

This is critical to be able to scale. You should avoid sharing state ( including browser session ) between the tests and creating tests scenarios that are a succession of @Test methods. Each @Test method involving some web steps will have its own browser, destroyed at the end of the method.

Especially it's not a good idea to use TestNG "dependsOn" to handle things like sign in by having

 @Test
 public void signIn(){
   // sign in with user A
 }
 
 @Test(dependsOnMethod="signIn")
 public void myTest(){
 // do something assuming the user is already signed in. 
 }

instead, use a single test using PageObjects. @Test public void myTest(){ SignIn page = new SignIn(); page.signIn(user,pass);

   // test something with you user.
   }

and keep the "dependOn" for validation. End to end tests with Selenium are slower than unit tests. You can save a lot of time by checking what you would normally do manually : skip the tests on any feature that require sign in if you see that sign in is down.

 @Test
 public void testSignInUp(){
   SignIn page = new SignIn();
   page.signIn(user,pass);

   // some validation
 }
 
 @Test(dependsOnMethod="testSignInUp")
 public void myTest(){
   SignIn page = new SignIn();
   page.signIn(user,pass);
   
   // test something with you user.
 }

That way myTest() remains isolated and if the sign in functionality is down, the tests will be skipped, saving a lot of run time and creating a clearer report.

TestNG features are useful.

so don't limit yourself by keeping @parameter for the browser for instance. Use the testNG features for testing, not for the internal selenium plumbing.TestNG listeners are better suited for that.

Browser configuration isn't part of the tests.

A test involving some web steps will require a browser. This is part of the configuration of your test run, not something QA should reinvent for each test.

Tests code should be about validating your site works!

Not everything is web based.

Selenium isn't a test framework. Combined with a test framework like testNG it enables you to control a browser, but using selenium doesn't mean you now have to have everything happening in a browser. You need to be able to mix web and non web tests in your end to end suite. For instance :

 public class FeatureXYZTests {

 @Test
 public void myApiCall(){
   // test some API.
 }

 @Test
 public void myWebTest(){
   // and now some web stuff
 }

 }