2 minute read

Developers need fluency in technologies that the team uses for UI testing. Similarly, testing has become more a programmer's job than a point-n-click task. As the world's most widely-adopted web UI testing framework, Selenium is a must-know technology for responsive web development teams in order to maintain the pace of continuous delivery.

Mostly Working, Somewhat Broken 'Builds'

I use the term 'build' loosely here when it comes to web apps, since it's often more like packaging (particularly with Docker containers), but the idea is the same. You have code in a repo, that gets sucked in by your CI system, built/packaged), tested/validated, then deployed somewhere (temp stack or whatnot).

If the build succeeds but tests fail, you need to quickly assess if it's the test's fault or the new build. The only way to do that quickly is to maintain proficiency in technologies and practices used to validate the build.

Code in production is where money is made; broken code doesn't make any money, it just makes people move on. Everyone is responsible for the result.

We have a QA person. That's their job.

Not so fast. In continuous delivery teams, developers don't have the luxury of leaving it to someone else. When build verification tests (BVT) fail, a developer needs to track down the source of the problem which typically means parsing the test failure logs, referring to the code and the context/data used for the test, then making some adjustment and re-running the tests.

Though your test engineer can fix the test, you still have to wait for a developer to fix problems in code. Why not make them the same person?

Of course I'm not suggesting that every developer write ALL their own UI/UX tests, there's a division of labor and skills match decision here which each team needs to make for themselves. I also thing in larger teams it's important to have separation of concern between those who create and those who validate.

Code in production is where money is made; broken code doesn't make any money, it just makes people move on. Everyone is responsible for the result.

How can web developers find time for UI testing?

The answer is simple: do less. That's right, prioritize work. Include a simple test or two in your estimation for a feature. Put another way, do more of the right things.

You may get push-back for this. Explain that you're purposely improving your ability to turn things around faster and become more transparent about how long something really takes. Product owners and QA will get it.

Now that you have a sliver of breathing room, learn how to write a basic Selenium script over what you just created. Now you have a deliverable that can be included in CI, act as the basis for additional validation like load testing and production monitoring, and you look very good doing it.

You can do it!

Obviously, you can go to the main site, but a quick way for those with Node already installed is through WebDriver:

require('webdriverio')
    .remote({desiredCapabilities:{browserName: 'chrome'}})
    .init()
    .url('http://www.github.com')
	.setValue('.header-search-input','perfectomobile')
	.submitForm('.js-site-search-form')
    .getText('.codesearch-results * h3').then(function(value) {
        assert(value[0].indexOf('repository results')>-1);
    })
    .end();

[full tutorial here]

For those who have never worked with Selenium before, start with this tutorial. Then go through the above.

Even if you aren't a Node.js fan, it's an easy to grasp the concepts. If you want to go the Java or C# route, there are plenty of tutorials on that too.

More reading:

 

You may also enjoy