Zeenyx Software

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home3/zeenyxor/public_html/b2evolution1/inc/plugins/model/_plugins_admin.class.php on line 1466

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home3/zeenyxor/public_html/b2evolution1/plugins/_auto_p.plugin.php on line 502

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home3/zeenyxor/public_html/b2evolution1/plugins/_auto_p.plugin.php on line 500

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home3/zeenyxor/public_html/b2evolution1/plugins/_auto_p.plugin.php on line 500

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home3/zeenyxor/public_html/b2evolution1/plugins/_texturize.plugin.php on line 116

Design patterns are often used in the development of object-oriented software. A design pattern is a description of a commonly occurring problem along with a template for a reusable solution. There are many opportunities to apply design patterns to automated testing to make tests more reusable and easier to maintain. In the next several blog posts, we'll explore several examples.

According to the authors of ‘Design Patterns: Elements of Reusable Object-Oriented Software’, a design pattern has four basic elements: the pattern name, the problem, the solution and the consequences of applying the pattern. The pattern name consists of a few words to describe the pattern. The problem describes when to apply the pattern. It explains the details of the issue and its context. The solution provides an abstract description of the resolution. Because the solution is meant to be reusable, it may provide a template for the design, rather than a concrete implementation. Finally the consequences examine the costs and benefits of applying the pattern.

Pattern Name: MultiWaitForWindows

Problem: In the sequence of actions in an automated test, it is possible that the application under test (AUT) may respond to a user stimulus by invoking none, one or more windows based on some characteristic of the transaction or data used in carrying out the transaction. Let’s take for example, the transaction to order an item from an ecommerce site.  It is possible when adding an item to a shopping cart that the web store might pop up one of many possible windows based on the item to be purchased. For example, the site might try to upsell or cross sell the customer or the site might deliver a message alerting the user to a back order or out of stock condition. While a given application might present a different possible set of windows, the problem itself is a common one.

Solution: The solution to the problem must be able to handle three possible conditions in the transaction flow:

• No window will be displayed
• One window will be displayed
• A sequence of windows will be displayed

MultiWaitForWindows takes a list of possible windows that might be invoked by the AUT along with a timeout that specifies the maximum time to wait for a window and an action to take if no window displays. The primary feature of the solution is the ‘while loop/for loop’ combination that waits the specified time for a window to display.  If no window displays, control is passed to the switch statement which carries out the instruction provided in the ReportAction parameter.

Consequences:  Note that there is no attempt within MultiWaitForWindows to handle the possibility of a sequence of windows. There is a good reason for this and the pattern itself does, in fact, provide a solution. Consider that the AUT may invoke a window that requires some application-specific response, while other scenarios may require only that the window be accepted (‘OK’) or dismissed (‘Cancel’). It would complicate the solution to require an action to take for each possible window. Instead, the pattern proposes that the active window (if there is one) be returned to the caller. It is left to the caller to decide how to handle the window should it be displayed. In situations where a sequence of windows might be displayed, MultiWaitForWindows can be called within a loop where application specific responses can be specified for each window. While an application-specific solution could be designed to handle each possible sequence, the pattern provides a simple solution that is reusable.