The coded ui test architecture has several interfaces to extending classes. The architecture as a whole is described in this image from msdn (

The interface that this extension focuses exclusively are the "Test action filter" and "Test action aggregator". This places the extension exclusively on the recording side of coded ui test creation, rather than playback. This constraint may seem overly limiting, but it actually makes the extension much clearer and easier to maintain and improve.

Action filters interact with the recorder solely through the "action stack". Whenever the user takes an action, a UITestAction is created and placed on the top of the stack.

After the system modifies the stack, all action filters are called with a reference to the stack.

The filter is allowed to then make arbitrary changes to the action stack. This includes deletion, reassortment, changing in-place, and adding new actions. You are limited by the existing UITestAction subclasses, though in most cases this isn't relevant as all you want to do is add clicking and typing actions.

After the filters have all acted, the new action stack persists, and the next user action is placed on top of it once the user continues. Otherwise, if the recording is paused and generated, this will be the way the method is saved.

One extension is only able to provide one UITestActionFilter, which can make it difficult to organize code consistently in the action filter. In order to avoid this issue, the AX Extension defines its own abstraction for filters, which includes other utilities. The primary function of the Filter abstraction is to separate concerns more than a monolithic UITestActionFilter would.

Last edited Jul 30, 2014 at 4:29 PM by wgoodin, version 8