Maybe you're not a "people person." It's not that you dislike other humans,
but you recognize certain realities of your work. Your day job is maintaining a
web application, after all, not carousing with your users. You know that
accessibility is an important topic, but you haven't been able to find the time
to learn more about it. Keeping the application running smoothly while your
team adds features, fixes bugs, and re-designs is quite enough to worry about,
thank you very much. That introduction to accessibility
has been open in a tab for the better part of a week, but the UI tests are
failing again. Is it any wonder that "a11y" concerns take a back seat?
Recently, I had the opportunity to contribute to a massive, meaningful effort: the open-source Web Platform Tests (WPT) project. My task was to improve WPT test coverage for areas of the HTML specification dealing with navigation —things like the details of loading new web pages, browsing around the web, and opening new windows.
I didn’t anticipate that I’d stumble onto a bug affecting several browsers that dates back nearly 20 years, in one of the most established areas of the HTML specification.
How Web Platform Tests make the web better
Illustration by Sue Lockwood
of tests for the language. The name of that test suite is Test262. When we
started extending Test262 to cover brand new language
features, we knew we were in for
In the beginning of 2015, we started another important project for the open
web. Of course you haven't forgotten, but for all the folks just joining us:
Google and Bocoup teamed up to improve
Test262, the official test suite
web platform (not just the V8 engine) as a
base for application development. We focused on improving coverage for new
features being introduced by the then-unfinished ES2015
specification, but we cast a
wide net for ways to add value. The eighteen months that followed have been
crammed full of adventure, discovery, and beauty. We filed hundreds of
bugs on V8 and
and landed dozens of patches to V8 and to the specification itself. There's
even been some derring-do! In this post, we'll recap some of that magic and
share our ideas on how to prolong it.
Sometimes I'm not satisfied with the way things are. I wish they could be a
little bit different, just for a moment. I deal with this desire in my personal
life by sighing and gazing through a rain-dotted window. When writing code, I
take a more productive approach: I use seams.
August 14, 2015. Mark your calendars. That's my next birthday. Another
important date is June 18, 2015--it's when the ECMA General
Assembly will vote on and
On that day, all those new language
features we've been
coveting/dreading will officially enter our lingua franca. Today, Bocoup is
starting on an exciting collaboration with Google and TC39 to prepare for the
big day. Before we get into that, though, we should talk about what needs to be
done in general.
Selenium is an indispensable tool for developing web
applications. It allows developers to write test scripts that control real
browsers and ensure their applications behave in the way that users expect.
Tests like these make software development much more pleasant--developers can
have much greater certainty that their application is functioning correctly
even after large refactoring operations.
There's a dark side to UI testing, though. So-called "race conditions" can lead
to unexpected and intermittent test failures. Such failures undermine developer
confidence in their test suites at large, and this subverts the entire
motivation for maintaining tests in the first place.
I’ve always been a huge proponent of building sites that work everywhere — any user, any browser, any device, any context. Websites work everywhere by default, and they stay that way so long as we know how not to break them. That’s what the Open Web means to me: ensuring that entire populations just setting foot on the web for the first time will find it welcoming, regardless of the devices or connections used to get there.
For many developers, writing tests is a hassle that would be best put off till
tomorrow. For one, nothing can compete with the direct impact of writing great
application logic. No user ever shared feedback like, "The UI was really
pleasant and the functional tests were well-organized and readable." There's
not much I can say to change that.
Another common hurdle is that maintaining tests can just be a slog. Whether
it's deciphering the crazy code written by another developer or just trying to
avoid writing unmaintainable logic yourself, the open-ended nature of testing
has given pause to plenty of programmers.
specification for structuring modular code.
with blog posts illustrating its use in front-end application development (and
debate around its
necessity, too). The topic of unit testing (despite being integral to the
process of software development) does not receive much attention in these