In this post, I’ll explore how I’m starting to provide a data builder pattern with Symbiont. The specific focus is on how you supply data to page definitions as part of your automated test logic.

I’ll assume you’ve read the previous posts in the Symbiont category and thus you understand how Symbiont uses page definitions that declare assertion and element definitions. For this post I’ll be using the warp factor calculator area of the Dialogic site. If you want to try the logic in this post, I recommend downloading a local copy of Dialogic.

To keep things simple, I’ll just put everything in one file here rather than breaking things out into separate files. So first create a script.rb file. Start it off like this:

Here I’ve declared a working page definition for some of the moving parts of the Warp Factor Calculator page.

The idea with the page (and thus the page definition) is that you want to specify data to those particular text fields. If you went through the post where you logged in to the Dialogic site, you saw that you could specify data by passing it to a method on the page definition. Specifically you had a call like this:

Let’s do something similar with the warp data initially and then we’ll use that to build up to different ways to utilize data.

Default Data

Let’s use the Symbiont factory to use the Warp page definition and call an action on that page definition to calculate the warp.

Here I’m just calling a calculate_warp method. Obviously such a method doesn’t exist yet so I need to create it. Yet notice here that I’m not passing any arguments. This means I’m counting on some default data being used. Yet I know that in some cases I will want to use specific data. So my action needs to take account of both possibilities.

Exercise: Depending on your Ruby skills, you may want to try to code up a method called calculate_warp for yourself.

Below is a possible implementation:

The elements to note are the DEFAULT_DATA constant and how that constant is used in the calculate_warp() method. Specifically, the contents of the DEFAULT_DATA will be merged into the data that is passed in. The way Ruby merge works is that any value for entries with duplicate keys will be that of the passed in data parameter. So if no data is passed in, all of DEFAULT_DATA will be merged in. If specific data is passed in, however, that specific data will be used.

So the practical upshot is that I’ve provided default data on the page definition for the warp factor; specifically, if no data is specified in the call to calculate_warp(), then the DEFAULT_DATA will be used.

Now let’s try to pass in some values:

Here I’m saying the distance to compute for should be 12. What happens now is that the DEFAULT_DATA is merged in as before, but since I have specified one data element of that default data, my specific value (12) will be used in place of the DEFAULT_DATA value for distance (4.3). The other values will be those from the DEFAULT_DATA hash.

You could of course use specific values for all of the fields, like this:

This isn’t bad but do note that it the arguments you pass in do not necessarily have any connection with the objects (elements) for which the values will be applied. All you pass in are strings and while, in this case, I made those strings the same identifiers as the element definition methods, there is no actual correspondence between them.

Data Setting

Symbiont provides a DataSetter module and it builds off of the base or default data idea.

As you saw with the default data concept, you can have hashes of default data in your page definitions. Symbiont allows you to specify that default data on the fly by simply specifying what data you want to use. Here’s an example of a script that does just that:

Here the difference is calling the method using_data. If you run that script, you’ll see that the page starts up and the warpFactor field (defined as an element definition, remember) populates with the value you specified. If you don’t like using symbols, you can use a string:

Here the key is the using_data action which tells Symbiont to match up whatever data is passed in via the action with element definitions. If those elements are found, they will be populated with the specified data. You can send in more data, just as you could with the calculate_warp() method:

You might wonder how this is better than simply using default data and passing in more specific data. After all, with that you could just do this:

There are a couple of differences. Note that the using_data action does not have to be run against a specific method. It is its own action that takes place in the context of a page or activity. Also note that the above use of calculate_warp() method does require a DEFAULT_DATA hash that is merged in, to allow for the case where no data is specified at all. On the other hand, the using_data action has no provision for merging in base data.

You can decide what approach you want to use. They are not mutually exclusive.

Another thing to note about the using action — as well as the default data mechanism — is that they are predicated upon data, as opposed to actions. That means, for example, that you don’t pass in actions like “click this button”. However, you can indicate that you want to check a checkbox or set a radio or select an item for a select list. To test this out, let’s use the Practice page of Dialogic.

Create a page definition like this:

Let’s say you want to go to the page, set the name text field, check a specific checkbox (enableSith), select a specific item from a select list (power), and set a particular radio button (multiphasic). Then you want to uncheck the checkbox that you previously checked. Here’s a script that can do just that:

You’ll notice there that I’m calling a using action instead of using_data. In fact, they are aliases of each other. All of the following method names can be used, based on what you feel reads the best:

• using
• using_data
• use_data
• using_values
• use_values

What this post showed was a convenience mechanism for setting data within the context of a given page or activity. Would you use this often? Hard to say. I showed above that it can have uses. The reason I put this into Symbiont was because I see this “data setting” mechanism as being the base for more structured data handling. In other words, other modules of Symbiont can build on this relatively simple base to provide a means of indicating the data for specific actions that must take place in a given context.

At the start, I said that I’m providing a data builder pattern with Symbiont. The data setter mechanism is the first aspect of that.