In the last chapter, data-driven test classes and methods were designed and built to demonstrate how to use TestNG annotations and parameters to design and build test, setup, and teardown methods. In this chapter, we will dive further into the topic of test data. From what we have learned, encapsulating data into central locations and breaking it out from the test methods and page object classes is an important standard to follow.

What we need to understand about test methods versus test data is this: test methods should be small engines that perform a task, can take any variation of data, and that can test positive, negative, boundary, and limits of a feature. There is always an input and a verifiable output to a test. If users follow this rule, then simple "keyword" templates can also be built on top of the framework that allow users to extend test coverage by adding "sets" of data to run through the engines.

So, when designing the test framework for a development environment, put this standard in place from day one, code review tests that are added to the framework, and evangelize the use of a data file, property file, or global constants file to store data. Let users fear the code review process so the framework does not become the Wild West. And most importantly, let them know that rule number one is do not get caught! (storing data in your tests or libraries, that is!).

This chapter will also cover how to switch between multiple WebDrivers running simultaneously, including web and mobile drivers. And finally, the topic of parallel testing will be introduced and discussed as to what is involved in implementing it.

The reader will learn how to encapsulate test data for use in data-driven testing, including use of property files, dual-drivers, and parallel testing.