-
Notifications
You must be signed in to change notification settings - Fork 0
Using ranges
Ranges are referenced just like properties but they change every time you reference them. By change it means that the range moves its internal cursor forward so that it can take on the next value in its defined range. There are a few types of ranges expressions identified here . When using ranges you have to decide early on if you want to make the range recyclable with the attribute recycle equal to true or if you know that you've defined a range with enough elements for test execution you're writing. If you run out of elements in a range you'll get the NoMoreResultsException thrown to mark the end of the range values.
When using ranges from multiple threads remember that ranges are globally accessible and therefore share their values across the multiple threads in a test case. This means you have to be even more careful to not run out of elements when taking into account the multiple threads that can pull values from the same range.
Ranges can be carried across to components and used from there but they return to the runner in their exact position as they left the component. This can probably be explained in the following XML script.
<?xml version="1.0" encoding="UTF-8"?>
<script xmlns="http://dtf.org/v1" name="ranges_and_components.xml">
<info>
<author>
<name>Rodney Gomes</name>
<email>rlgomes@yahoo-inc.com</email>
</author>
<description>
</description>
</info>
<local>
<lockcomponent id="C1"/>
<createrange name="range" value="1,2,3,4,5"/>
</local>
<component id="C1">
<for property="i" range="1..5">
<log>value ${range}</log>
</for>
</component>
<!-- the range is still in the same position on the dtfx side -->
<assert><eq op1="${range}" op2="1"/></assert>
</script>You can see how we're able to still assert that the range's value is still 1 even after we've cycled through all the elements on the component that was used during this test execution.