In our last blog, How To – Automate BBT graph, we begin to understand the simplicity of automating a BBT cause and effect graph by creating scripts of an example behavior for each objects an understanding how to handle negative and positive states of a test scenario. In this blog, we will improve our scripts to be as effective and efficient by diving deeper into creating flexible scripts that allows maintainability simple when requirements changes in our application by only updating our cause and effect graph.
Starting with a basic example of a login behavior which requires a user to land on login page, enter username, and password to successfully login to an application in order to simplify understanding of data driven scripts more effectively. This is a very basic example to demonstrate the use of true states and false states as these functionality provides us the ability to handle conditions and/or entering data by storing and calling dictionaries key/values from our true/false states as seen below in our example:
Each individual columns, for example ‘username’ in Reporting Username context, are keys (column) for each values (row) we provide in the true and false state. Generating test cases for these contexts, events, and outcome will generate both negative and positive test cases by accounting true/false states in the permutations engine which provides us with better coverage for our functionality, in addition, provides the ability to create data driven scripts to increase the flexibility and maintainability of our scripts. To understand how we can utilized data tables in our objects (contexts, events, and outcome), we will need to understand how the data in our graph is being stored in the simplest form.
All data in an object is stored into a dictionary, see example below, where columns are the keys and the rows are the value.
In order to obtain the values within the dictionary for our script, we provide curly braces surrounding our key name to return the value to our script. In the example below, we are executing the keyword “ObjectSetValue” used to enter a value in a text field in the login page. By providing a key surrounded in curly brace we avoid hard coding any values, instead, we utilize the data table from the context “Reporting Username” to pass those values allowing us to update these values in the graph level making maintenance and reusability simple.
As an overview, we avoided hard coding our scripts to allowing reusability and by implementing this approach will have the benefit of maintaining automated scripts strictly within the cause and effect graph. As requirements are changing constantly, we can determine the benefit of creating a data driven script compared to a script with hard coded value by using BBT features to the fullest extends.