Nickolay Platonov
31 July 2018

Siesta 5.0 released

We are very excited to announce the new major release of Siesta – v5.0. While being new and shiny it […]

We are very excited to announce the new major release of Siesta – v5.0. While being new and shiny it is also very backward compatible, something we at Bryntum consider very important. Most of the changes are hidden behind the high-level API, you should be able to upgrade to Siesta 5 with very minimal code changes. In this post I will highlight the most important API changes and parts of the new functionality. Let’s dig in!

Modern browsers

Siesta 5 drops support for legacy browsers IE9 and IE10. This just means we will stop running Siesta’s own nightly test suite in those browsers. IE11 is still supported, but we are very interested in hearing your opinion about it – do you still support IE11 in your applications? We would like to make a mini-survey and kindly ask you to post a comment in this blog post, with the list of the browsers you run your tests in. Thanks a lot in advance.

Harness renamed to Project.

We found that the “project” term makes much more sense for the “harness” file. The purpose of the “harness” was to store the configuration information about your test suite. “Project” feels like a more natural term for this.

The documentation and examples have been updated to use the new name. We also reworked and updated the documentation along the way. You will find that it is now easier to find the relevant information.

NodeJS support

Siesta now supports running tests in NodeJS. It supports running both sandboxed (each test running in a separate Node process) or shared (multiple tests in a single process). Parallel execution (`–max-workers` command line option) is supported as well. This is naturally the fastest execution engine for Siesta, as there is no overhead of starting the browser process.

It is a different environment for writing tests as well. When writing tests for NodeJS, you just write your test as usual:

StartTest(t => {
    t.it("Ok assertions", t => {
        t.ok(true, 'True is ok')
        ...
    })
    ...
})

The test can be directly launched by passing its filename to the `bin/nodejs` launcher, which also accepts glob patterns:


Alternatively you can create a project file as before (the “harness” file):

const Siesta      = require('../../siesta/folder');
const project     = new Siesta.Project.NodeJS();

project.configure({
    title               : 'Awesome NodeJS test suite',

    autoCheckGlobals    : true
});

project.planDirectory(__dirname);

project.start();

Then simply launch the project as a regular Node.js script by passing its filename to the Node executable:

> node path/to/siesta/project.js

Please refer to this introductory guide for details.

Adopting Promises

All methods that simulate user actions now return Promises. For example, it is now possible to “natively” chain the types/click actions like this:

t.type(userNameField, 'username').then(() => {
    return t.type(passwordField, 'secret')
}).then(() => {
    return t.click(loginButton);
});

For this specific use case, the `chain` method still looks leaner though:

t.chain(
    { type : 'username', target : userNameField },
    { type : 'secret', target : passwordField },
    { click : loginButton }
);

A Promise can be returned from the test itself (Siesta waits until it is resolved):

t.it('Doing async stuff', t => {
    return someAsyncOperation().then(() => {
        t.is(res, 42, "Async stuff finished correctly");
    });
});

Combined with the `async/await` it becomes even cleaner:

t.it('Doing async stuff', async t => {
    let res = await someAsyncOperation();
    t.is(res, 42, "Async stuff finished correctly");
});

Similarly, Promises can now also be returned from a chain step:

t.it('Doing async stuff', t => {
    t.chain(
        // function step that returns a Promise (sugared with async/await)
        async () => {
            return await someAsyncOperation(t)
        }
    )
})

 

Native event simulation

Siesta 5 adds support for one more user action simulation mode – native events. Native events are “real” OS-level events which produce exactly the same actions as when performed by a real user. Here is a few examples of what this means:

Native event simulation can be very useful if you need to test some intrinsic browser behavior, which synthetic simulation can not reproduce (despite our best efforts to make it as close to native behavior as possible). Such scenarios might include testing SVG documents, tooltips, native drag and drop etc. However synthetic simulation will likely run faster and you will have to decide yourself which mode that is best suited for a particular test.

For more details please refer to the documentation.

Siesta Lite published in Npm

Siesta Lite can now be installed from the npm package repository:

> npm install siesta-lite --save-dev

Internally, Siesta now looks a lot more like a any other “normal” JavaScript package. It was trivial to publish it in Npm, and we hope this will make it easier for users to get started with Siesta.

New React example

We have added a new example demonstrating how to test a sample React application – GFontsSpace.
It mostly involves patching / cloning existing Webpack configuration files.


All details are described in this guide. You can follow the same approach in your project even if it is not based on the “react-scripts” as GFontsSpace.

Conclusion

Siesta 5 is focused on the modern JavaScript ecosystem. We would be very happy to learn more about your specific testing needs in this area. Please just drop us a few lines in our forum and send us an email. Happy testing!

Download in customer zone

Nickolay Platonov

Product updates Siesta