A look at the upcoming Siesta recorder

Lately we’ve been hard at work at getting the new Siesta event recorder ready for release. So far it’s looking pretty darn good and in this blog post I want to share some details of how it works and how you can use it to save time writing your UI tests.

What is the Siesta event recorder?

The event recorder is a new part of Siesta that can record user interactions with the test UI. As you click, drag and type in your application or component UI, it will record the events and allow you to play them back. Once you’re happy with the result, the recorder can output Siesta test code that you can easily copy paste into your test file. Creating UI tests this way you will save lots of time compared to coding each test manually. We see two main use cases for the recorder and we’ll cover both in blog posts coming shortly. Here’s the UI of the recorder:

For the UI developer

First we start with the UI developer perspective, i.e. if you’re developing Ext JS components or any component that’s a part of a bigger application. You should of course first aim to cover as much of your UI component code with unit tests, but you should also make sure your UI component actually can be rendered and interacted with. This is easily done by creating and rendering your UI component in a test and then simulating the events that prove that it actually works. As part of writing the recorder, we’ve used our own components as test subjects and thereby gained a nice test coverage boost of our Scheduler/Gantt code bases and even the Siesta UI.

For the QA engineer

This is a quite different perspective. Usually one or more QA engineers are responsible for assuring that an application works before a release can be made. When doing this type of “black box” testing in Siesta, we first visit the application URL (e.g. ‘index.html’) and wait for it to render. Then we record interactions with the application UI, exercising the most vital parts of it. This is of course a lot more complex compared to just testing an isolated UI component. First of all, a lot more code is executed than in the previous scenario and you also need to worry about things like login/logout, session state and restoring the database to a known testable state. The value of these tests is of course huge, since we can prove that the application as a whole actually works. Certainly nice to know prior to a big release. Though keep in mind, this type of testing should not be used to find low hanging fruit. Simple bugs that can be caught much earlier in the development process, such as code syntax errors or simple logic errors should be caught by unit tests (having a QA team find such bugs is very expensive).

Below is a video showing how easily we can test one of the Ext Scheduler examples that we ship as part of the Ext Scheduler SDK. It would be embarrassing for us to ship a broken sample to our customers, so why not simply make a smoke test for it? You’ll note that the entire test is produced in just a few minutes.

[youtube id=”ELkWGOGOq9E” width=”550″ height=”300″]
 
Here is the code generated by the recorder, which is ready to be pasted into your test suite. You can see that Siesta has used multiple Composite Queries (Component Query + DOM Query) to target the buttons clicked.

[crayon striped=”false” lang=”javascript” nums=”false” toolbar=”false”]
t.chain(
{ waitFor : “EventsToRender”, args : [] },

function (next) {
var cmp = t.cq1(‘schedulergrid’);

t.willFireNTimes(cmp, ‘viewchange’, 11);

next();
},

{ action : “click”, target : “schedulergrid button[text=Seconds] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Minutes] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Hours] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Days] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Weeks] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Weeks 2] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Weeks 3] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Months] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Years] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Years 2] => .x-btn-inner” },

{ action : “click”, target : “schedulergrid button[text=Day and night shift (custom)] => .x-btn-inner” }
);
[/crayon]

More to come…

This is just the beginning and there will be more blog posts about the recorder coming shortly. The recorder is currently in a beta phase, and if your company is interested in helping us test it out and report bugs to us, please send us a note. Please note that recorder will only be available in the Standard version of Siesta. If you have any ideas or feedback of what features should be part of the recorder, please make your voice heard in the comments or our forums.