Last Updated: September 09, 2019
·
6.057K
· otupman

Going further with Angular E2E tests: extending the Scenario DSL

Angular provides an awesome End-to-End (E2E) DSL that allows one to write simple tests. The following example, taken from the Angular E2E tests, shows how to write a test to verify that the location of the browser is pointing towards www.google.com

expect(browser().location().href()).toEqual('http://www.google.com')

E2E works on the idea of expectations; the API - browser(), element(), etc. return 'futures' - essentially a thing that will be satisified or have a value at some point in the future.

The E2E API is pretty good, but in the case of the Lungo Angular Bridge, we need to be able to test the integration between Lungo (our chosen mobile UI framework) and Angular; this means we need to do some advanced testing.

The following is some Angular E2E magic to check to see if an element is visible:

expect(element('#someElement:visible').count()).toBe(1);

We're using the visible selector for jQuery (that E2E uses) and just making sure there is 1 element that matches.

Now Lungo uses CSS3 to perform it's transition effects; these use things like -moz-transform and the value of this is the value appears, in E2E, as a string like this: "matrix(1, 0, 0, 1, 0, 0)".

The LAB tests need to determine if one of those values (the X transform) is greater than 0 - we can't do that via a normal E2E test because, at the point of executing the normal API, we don't have a value.

Enter our addition to the DSL:

angular.scenario.dsl('xPosition', function() {
    return function(selector) {
        return this.addFutureAction('xPosition', function(window, $document, done) {
            var transform = $document.find(selector).css('-webkit-transform');
            var splitTransform = transform.split(',');
            done(null, parseInt(splitTransform[4]));
        });
    };
});

The key part there is the call to done(error, value); there we're supplying the value that this future is returning. If we encountered a problem, we could specify an error (as opposed to null).

And to call, we can use all the usual matchers, so the test I'm writing can perform the following:

xPosition('#someSection').toBeGreaterThan(0);

Currently all we need is the x position of the section; eventually we'll test more than one dimension, so I suppose we'll change to the DSL to position(selector, dimension)

1 Response
Add your response

Nice post, but I think that this would be the correct way to perform the test:

It should be expect(xPosition('#someSection')).toBeGreaterThan(0);
over 1 year ago ·