In response to the problem raised at the beginning of this chapter and for any similar matters in the future, we have seen how to transition from simple record and playback tests to data-driven architecture by releasing the test from the hardcoded values and binding its input to various types of data sources. On one hand, the binding was demonstrated for simple UI controls which already expose a readymade property, and on the other hand for more complex UI controls where the binding had to be customized in code. This is not all, since binding does not confine only to UI controls where we have learned how to bind data columns to verification steps also. We have also highlighted dynamic filtering on data sources, where the set of the executing rows can be evaluated and retrieved based on automation criteria just before the test executes. A powerful feature inside Test Studio was also explained and illustrated in the examples discussed previously. This happens when one test is nested inside another. Depending on the nature of the tests, whether data-driven or not, the execution flow, and transmission of data varies from one scenario to the other. The three possibilities are calling a data bound test from a regular one, calling a data bound test from another data bound test, and finally calling a regular test from a data bound test. The aforementioned feature list constitutes the solid ingredients to implement data-driven tests to resolve automation needs for the applications under test. With this, we conclude this chapter and present hints and solutions to fit your testing environment.

The next chapter deals with the test scripts building blocks, which are the UI screen elements that the steps interact with. We will discover Test Studio's default generation for element definitions and how we can edit them to improve test reliability.