Done with the TestNG Data Provider with Excel

So I started off coding in the second week as the first week went in writing down the test scenarios. I wanted to try the @DataProvider annotation available in TestNG to carry out a generic log in test to see if it works properly. I wrote two tests, first one was Data Provider with a Java class and second Data Provider with Excel. The first one was straight forward and just needed a java object which can provide multiple parameters. The object looks like this with the @DataProvider annotation:

public class LoginDataProviderTest extends commonTest
{
@DataProvider(name = "Authentication")
public static Object[][] credentials()
{
return new Object[][]{{"dummy1","dummy1"},{"dummyUsername","dummy_password"}};
}
@Test(dataProvider="Authentication")
public void canUserLogin(String username, String password)
{
//loginPage.Goto();
loginPage.loginAs(username)
.withPassword(password)
.login();
Assert.assertEquals(loggedInCheck.isAt(), true, "Login failed");//actual,expected
}
}

This was a one step method and the test ran right away. The second approach had three steps and I found it more useful. For using Data provider with Excel, the following steps need to be followed:

1. Create an excel.
2. Read data from it.
3. Execute script.

Again, the first step is like creating a normal excel but while entering data, we should be careful about what data is entered in which column. Like if I have to test for login and I decide to test for 4 cases then i need four combinations of username and password. To take care about that it should be insured that the first column contains the username and the second password corresponding to the respective usernames or vice versa. Something like this:

UserName	Password
dummy0	dummy0
dummy	dummy

The second step is reading data for which I used Apache POI.. It is a Java API for reading Microsoft  documents. The APIs are seamless and can be implemented easily for excel. And the last step was pretty much the same script, the only addition was calling the ExcelReader Function with file path and sheet name.

I found the second approach useful because even if the person running the tests does not know anything about programming can go directly to the excel and add further combinations for test. The only limitation is that  she/he should know how to edit Excel :P.

All in all the first task went well. The code can be found here.