During the design and creation of LoadStorm, it became apparent that a standardized communications framework would have to be used. In other words, creating a syntax of HTTP requests would be a necessity to proper work flow. Fortunately, there were a number of generally well-known commands as described by the Selenium program interface.
Just as in Selenium, the LoadStorm LoadGenerator requires several types of locators for various HtmlElements. The selected locators as implemented are identifier, id, name, xpath, link (for HTML anchors), and some default behaviors when the locator type is not specified. The only difference between Selenium and the LoadGenerator is the absence of dom locators. In fact, the variety of locators available is greater than LoadStorm requires. Every test sequence passed to the LoadGenerator will be automated from a user’s actions. The typical locators used by LoadStorm will most likely be extremely explicit such as xpath or identifier if the id or name is particularly unique within the page. This indicates that user-specified scripts may not remain valid if substantial alterations are made to the target site.
Many commands mapped directly from the Selenium user interface to HtmlUnit’s HtmlElement methods. Additionally, to meet our own standards of syntax under development much prior to the introduction of Selenium, some relabeling was in order.
Selenium has a system of assertions to check for correctness of the text and/or various HTML items appearing on the page. The checks as implemented by Selenium fall into two different categories: assertions and verifiers. The key difference between the two is one will stop the execution of the test sequence. This is not the desired behavior of the LoadStorm LoadGenerator. Test sequences must run to the end of their test sequence unless serious error in connecting/requesting information from the target server occurs. Therefore, all assertions were not implemented and the two important verifiers were mapped in:
-verfiyText()
-verfiyTextPresent()
Unfortunately, there is no verifyValue for text entered into a text field or preexisting in a text field. This could be worked-around in HtmlUnit using asText() or asXML() method calls. The absence of particular elements on the page, such as radio boxes or menus will be expressed as a failure of the test sequence which choose to modify them.
Selenium supports String match patterns which are used to find elements fitting a particular
String regular expression or wild-card. This utilizes the power of JavaScript regular expressions. Java also has a method of using String match patterns. However, this design was not considered a useful feature. In the end, it is not implemented at all in the current version.
Selenium tends to use the click() command almost exclusively. This was a natural conversion to the HtmlUnit’s click() method available to all HtmlElements. The Double-Click() in HtmlUnit is a tool of JavaScript. It can be called from HtmlUnit as well in this fashion. However, its functionality is different. The double click currently implemented simply calls the Click() method twice on the same location. If JavaScript is implemented in the near future, then the intended implementation of this method will certainly change.