Selenium Test Project Management
I have general questions about selenium web project management, below is an example: my question is how to manage these test cases (its only 3 for example, real test cases are over 1000)
Is a class good for sub-tests, for example a class for logging, and all tests related to logging are under this class?
Are there conventions for writing and managing test cases?
Thanks everyone.
I create class with tests like:
@Test //Test1
public void logInFaildTest() {
GridTest gridTest = new GridTest();
WebDriver webDriver = gridTest.getWebDriver();
String url = gridTest.getUrl();
LoginPage logIn = new LoginPage(webDriver, url);
String userName = "user";
String pass="pass";
logIn.login(userName, pass);
WebElement errorMsg = webDriver.findElement(By.className("dijitToasterContent"));
String actual = errorMsg.getAttribute("innerHTML");
String expected="Incorrect user name or password. Please try again.";
assertEquals(expected, actual);
webDriver.close();
}
@Test
public void loginSucsecc()
{
GridTest gridTest = new GridTest();
String url = gridTest.getUrl();
WebDriver webDriver = gridTest.getWebDriver();
LoginPage logIn = new LoginPage(webDriver, url);
String userName = "user";
String pass="pass";
logIn.login(userName, pass);
String actual = webDriver.getCurrentUrl();
String expected= url+"#lastmile/";
// webDriver.close();
webDriver.quit();
assertEquals(expected, actual);
}
@Test
public void accountLock()
{
GridTest gridTest = new GridTest();
String url = gridTest.getUrl();
WebDriver webDriver = gridTest.getWebDriver();
LoginPage logIn = new LoginPage(webDriver, url);
String userName = "user";
String pass="wrong";
for(int i=0;i<11;i++){
logIn.login(userName, pass);
logIn.clearFileduNamePass();
}
WebElement msg = webDriver.findElement(By.id("dijit__TemplatedMixin_0")); //block message
String actual = msg.getAttribute("innerHTML");
int splitIndex= actual.indexOf(".<");
actual = actual.substring(0, splitIndex);
String expected= "Your account has been locked";
webDriver.quit();
assertEquals(expected, actual);
}
}
source to share
Yes, what you did is only good. So all Login related operations can go into one class, so if there are any changes, we can easily deal with the fact that
Facility support
You can use the Object Object Model (POM) as it is widely used and easy to manage. This is for managing your objects more like keeping an object repository
As you can see, all we do is find the elements and padding values ββfor those elements.
This is a small script. Script maintenance looks simple. But over time, the test suite will grow. As you add more and more lines to your code, things get tough.
The main problem with Script maintenance is that if 10 different scripts use the same page element, with any change to that element, you need to change all 10 scripts. This is time consuming and error prone.
The best approach to serving Script is to create a separate class file that will find, populate, or validate web elements. This class can be reused in all scenarios using this element. In the future, if there are changes to the web element, we only need to make the changes to one class file, not 10 different scripts.
This approach is called the Object Object Model (POM) . This helps make your code more readable, maintainable, and reusable.
Test data maintenance
The next thing you need to consider is the test data used to run test cases with different datasets Validation based approach
Same as POM . You can create a factory class that will provide you with a dataset as needed so that when the data changes / changes, you can just go to the factory and change it.
To do this, you create a named class LoginData
that has type functions getValidCredentials
getRandomCredentials
to get your data. If your application requires a random email address for each run, you can just change only a portion getValidCredentials
This will help you a lot when your application is running mostly on forms or user data
Reusable components
Third, the reuse of what you've created. You can also reuse validLogin for another scenario
source to share