Blog


cucumberjs/protractor – dealing with non-angular popups

When creating cucumberjs/protractor test that involves dealing with a non-angular pop-up window, you can use combination of the getAllWindowHandles, and the ignoreSynchronization flag. The example below is a facebook SSO login (previous step was simply clicking link to login with facebook, to bring up the popup)


 this.Given(/^I login with facebook$/, function () {
        browser.getAllWindowHandles().then(function (handles) {
            var buttonName = 'fb login';
            browser.switchTo().window(handles[1]);
            // this switches focus of protractor the facebook login popup
            browser.ignoreSynchronization = true;
            // this tells protractor it's now a non-angularjs page
            fillField('facebook id', '{facebook login email');
            fillField('facebook password', '{facebook password}');
            return getVariable[buttonName.replace(/\s+/g, '')].click().then(function () {
                browser.switchTo().window(handles[0]);
                // this switches focus of protractor back to main angularjs window
                browser.ignoreSynchronization = false;
               // this tells protractor it's now a angularjs page
            });
        });
    });



Waiting for elements to appear/disappear with cucumberjs/protractor

The cucumberjs/protractor combination can be awkward, testing angularjs, and using chai-as-promised helped, but reliability still can become an issue. So I started to lean towards more purist protractor code in these circumstances, to get round issue that waits are not always intelligent in cucumberjs and chai-as-promised didnt always provide solution (but is still great extension!). This following code has proved a reliable wait function.


this.Given(/^I wait for something to finish$/, function () {
function waitForElementToNotBePresent(elementToWaitFor) {
		var EC = protractor.ExpectedConditions;
		var el = element(by.id(elementToWaitFor));
		return browser.wait(EC.visibilityOf(el));
// Or to check if element is not there, return browser.wait(EC.invisibilityOf(el));
	}
});

What is happening here is that protractor is waiting for the element to be be present or not, on page, before completing current step action.




What is the point of test automation?

  • February 23, 2016
  • Agile

Easily very little.  Whether it the most heinous and popular of crimes, the throwaway UI tests or (closely followed by) tests with test data and/or inter-test dependencies.  But even if all this is perfect, if it’s running on one machine, for one person, it’s just a good college project.  Or might as well be, for all the real use you get out of it.

The first step, after avoiding the perils of what’s outlined above, is to make it bigger. Drive tests using a specification language (i.e. natural language), but don’t forget to approach that as code, or too easily becomes a tangled library of accidental repetition.  The advantage here is quickly identifying common steps.  Everyone thinks their website UX is unique, but there is a lot that is common. Generating a good html report (with screenshots of failures), and a junit one for easy processing on systems such as Travis or Jenkins. Which brings me to important point – running tests on CI.

Integrating acceptance tests (which I what I generally call tester-generated automated tests).  It’s imperative to get maximum benefit from test automation.  The advantage of this approach, is it keeps tests lean and relevant and unique.  With no constrictions, you will no doubt have experienced testers or consultancies, who can generate hundreds of automated tests that provide “wow” factor, simply by quantity.  But run those same tests again and again, and the cracks will soon start to show.  Data dependencies, too many tests need updating with a code change, dependencies on other tests that start a cascade fail.  This is programming, remember, and same risks apply 🙂

While UI and API acceptance testing doesn’t replace unit testing, developers find the test framework useful in developing reusable tests (especially flexible API ones). Keeping in mind what is useful, and to who, help focus the mind.  My mind is very prone to veering off rapidly on tangents, so this was simple part of the way I learnt to avoid scatterbrained development.

Above all don’t play at it, do it. I have little patience for wasting time developing acceptance test frameworks that are unused.  Too many just “want it”, but don’t actually understand why, they just know it’s a “good thing”.  Which is why so many go through some consultancies pain before realising it can be a one-person job, well at least to kick-start it.

Manual tester are fast becoming a role that has become redundant in many ways, but others do not want to take it on. Hello to some PO’s and Stakeholders out there 😉 However, test frameworks and automation requires programming skills.  The best way to think about it is that’s it’s another developer on the team. (or more relevant test frameworks) can help bridge the old requirements to code gap.




Running Cucumberjs/Protractor tests using Phantomjs on Windows

Using gitbash ( from gitSCM) or similar Windows BASH emulation software:

  • npm install webdriver-manager
  • download window binary and extract somewhere
  • rename phantomjs.exe to phantomjs and copy to \\Users\[user id]\AppData\Roaming\npm

Change capabilities in conf file:

capabilities: {
browserName: 'phantomjs',
debug: true
}

webdriver-manager start

DISCLAIMER: I am not syaing this is the right way – this is the way I got the damn set-up to work on Windows 😉




Form filling using tables (Cucumber/AngularJS/Chai/Protractor)

Rather than pollute your Gherkin with “I fill in …” lines, you can create your own Gherkin and code, using table format. Many make mistaken assumption that Gherkin is somehow fixed format. Yes, the Regex trigger is the “Given”, “When”, “Then”, “And”. But Gherkin is supposed to be based on natural language, so as long as you observe some programming principles to creating new Gherkin, create your own. It’s encouraged as there is no way the out-of-the-box Gherkin provided by BDD products will completely accommodate your project requirements.