As we mentioned earlier in the book, the main reasons for using a data-driven test development approach are to be able to reuse test methods with multiple permutations of data, to encapsulate data in a central location, and to enforce DRY coding practices, which reduce the amount of code being written and maintained.

To correctly design and build tests that use this methodology for testing software applications, test methods must contain a predefined input, a verifiable output, and contain no hardcoded values within the test method. Data is passed into a test method at runtime, where it is then used in page object methods to perform an action and verify a result. Because the data is not hardcoded into the test, methods can be iterated with variations of datasets, extending the coverage of the test to include positive, negative, boundary, and limit testing.

This all sounds simple, but in reality, it takes quite a bit of work to convince and train an engineering organization to follow this model. With time constraints in releasing applications in continuous development environments, users often just build the test with a predefined set of data within it. Practices following a copy, paste, change one line of code approach are no longer acceptable.

Regardless of that fact, as a best practice and standard, test methods should be designed and built as generically as possible, use a data provider to extract and pass data to them, and stay small and focused on testing one function per test.

In this chapter, we will design and build data-driven tests using Java and the TestNG technologies.

As per Wikipedia:

The reader will learn how to create data-driven test classes that follow the Selenium POM to separate page object classes from test classes and data.