It's been several years since the initial release of my web app testing course, which I unfortunately needed to close down in early 2020 due to the content becoming very out-of-date.

Since closing it down though, I've been working on two follow up projects:

• The Web App Testing Guidebook, an e-book which I released on LeanPub last winter
• Web App Testing with WebdriverIO, a video course, which is currently in early access

Both projects share the same content, just in a different format. The reason for this is that I wanted to get the book written first, then start working on the video course. The reason for that is that it's easier to update text content than video content.

Knowing that I'd be working on all of this in my free time, I figured that by the time I finish the content, there will be parts that are already out-of-date (which definitely happened once or twice).

So with the book, I can take the time to develop all the examples, then go back and update them once finished, then more quickly develop the videos from those examples and hopefully avoid having to re-work the content (although it's already had to be re-worked once).

I'm currently in the middle of working on the course, with 10 videos completed and one more to go for the 'starter course'.

From there, I'll start working on the second part (there will be 3 total parts). It hopefully won't take my half a year to develop, and I have gotten into a much better rhythm with building out these videos. But still, the editing takes about a day for each video, so it'll take some effort still.

Anyway, I just wanted to make a note of it here. If you're interested in learning more about the course (or signing up hint hint), check out https://learn.webdriver.io

It's so tempting to rush through to the next step of the process before giving the current step time to set. The push is to keep moving forward with our momentum, even when the project just requires time to do nothing.

This phrase comes from the fun YouTube channel of Laura Kampf, who has a big block with the phrase on it. Viewers of the channel find the block simple yet profound.

Let Glue Dry.

Give yourself and your projects the space to set. Don't rush the outcome. Just because the glue isn't working yet, doesn't mean it won't work if you just give it time.

"Step back and listen."

It's a common phrase I hear among those asking for help. They talk about how frustrating it is when those in power tend to make things about themselves (e.g., the person in power would say, "It's really hard for me to know what to do." or "You should hear what happened to me.").

I was thinking about that, and why someone like myself would say the thing about it being hard or want to compare. Honestly, it is difficult for me to know what to do (which I've written about before).

Why is this so familiar? Why do people have such a hard time stepping back and not making it about themselves? Well, I think it's just human nature. We want to share our experiences, and in doing so forget whose voice we're talking over.

Unfortunately, it's only natural.

Okay, I'm not excusing that behavior. Not a single bit. We have to listen; we have to give room for voices of those desperate to be heard.

How do we do that though? How do we push down that evolutionary need?

We don't.

Instead of trying to act like our personal needs don't matter, we need to shift who we're telling those needs to. Ignoring our thoughts doesn't work, but directing it at the right audience does.

I've found personal counseling to be extremely helpful in this manner. Instead of having all my troubles loaded onto the shoulders of my friends and family, I have my therapist available to bear that burden.

After all, that's what they're trained for and that's why I'm paying them... So I can be an egotistical whiney mopey messy human being; the goal being that I contain that self-centeredness to the sessions, freeing me up to be emotionally available for my community and a more empathetic human being.

I brought this up with my wife and she mentioned that it reminded her of "Circles of Grief/Ring Theory". The idea is that, in a time of grief, you have those most affected in the middle of the circle, and those least affected on the outer rings.

We need to ensure that only comfort and empathy moves inward, towards those most affected. And in reverse, emotions are dumped outward onto those more able to bear them. "Comfort in, dump out."

Quoting the article I linked, ask yourself:

Where I am in the circle? Given that position, what should I say, or what can I hope would be said to me? Who are people in the circle I could comfort? Who can I "dump" to?

I really like this model. It recognizes the needs and unique experiences of all of us. I don't think you should ignore your own needs & worries just because you're not the most affected, but I also think those who are most affected desperately need us to be there for them, and to not make it about ourselves. We've got to get this right.

I'm definitely going to work on keeping this circle model in mind throughout my life, so I'm always emotionally ready to be there when needed, helping in whatever little ways I can.

Header photo by Annie Spratt on Unsplash

I've spent many years in the test automation world and there's one thing that sticks out to me: It's a wonderfully terrible thing.

It's wonderful in that it solves a very important need. Good automation can save immense amounts of time over the long run and catch bugs that would have made it to production.

It's terrible in that it gets used in the wrong ways, done for the very questionable reasons, and poor implementations can be a real maintainability nightmare.

But before I get to that, let's step back...

What is User Interface (UI) Test Automation?

Truthfully, test automation is a lot of things. There are a multitude of programs and tools surrounding it, not to mention the various ideologies about automated testing in general (e.g., Test-driven Development vs. Behavior-driven Development).

Aside from that, there are also different types of tests. Here, we're focusing solely on UI automation, but there's also unit, integration, performance, accessibility, usability, you-name-it testing.

All of these are important to know about, and can provide as much or more value than UI testing. So why focus on UI testing?

Well, you don't really have an option. You can't skip accessibility testing if you want to have a site that's accessible. Equally, you can't skip UI testing if you want to have a site that's not broken.

Truthfully, we're doing tons of UI testing. Every time someone loads up a website, they're testing the UI. When they click that button, does it make that thing happen? When I use my mobile device, does the site fit on my small screen?

If you have a site in production, every user is testing your UI. Hopefully for them (and you), they're not the first ones to try it out.

UI testing is constantly being done, just in a very labor-intensive way. Front-end developers working on the code will spend half of their day in the browser manually testing if their changes worked. If they're testing in an older browser, it will be 3/4ths of their day.

UI testing is the simple (hah) task of validating that the code written for the browser, actually works in that browser, along with all the other components that went into that webpage.

UI test automation is a way to convert those manual mouse clicks and keystrokes into coded scripts that we can run on a regular basis.

Let's Talk Benefits

I've alluded to this before, but it's worth repeating. Here are some of the many real-world benefits of automated UI testing:

• Jamie, your ace front-end developer, just finished their latest task and is itching to release it. While they were careful to validate that the new functionality works, unfortunately they forgot to test whether that new code broke the zip code widget on the contact page. Lucky for you, the UI automation test caught the error, and a fix was in place before the end of the day.
• Taylor is an awesome full-stack developer. They've got everything about their coding environment fine-tuned so that they can focus solely on pumping out fixes and new features... except for one thing: Taylor always forgets to check their code on slower, outdated computers. That's okay though, as our UI tests are configured to run on a variety of setups, and it just so happens that it caught that issue when running inside a Windows 8 environment.
• Casey is a great product manager, but sometimes forgets to clarify the small details. This means developers can make the wrong assumption during development, which is only discovered by Casey during product demos. By adding automated tests to the mix, developers and product managers are pushed to have regular conversations on the desired behavior of certain functionality, resulting in fewer surprises later on.
• Avery is a superb QA tester. With great attention to detail, Avery always thinks of unique ways in which the website would be seen. Unfortunately, manually testing these edge cases takes a fair amount of time to get in place. By adding automated scripts, Avery is able to programmatically generate the needed data for their tests, and allow them to run these scripts on a regular basis.

These are just a few ways test automation can help. I skipped over many other benefits for the sake of time, but there's one I omitted on purpose. Many folks claim that UI tests allow you to have fewer developers/testers. While that could be an outcome of automation, I don't think it's a valuable argument.

In all the scenarios above, having an extra human around wouldn't have necessarily helped. That's because human's have blind spots, and many of them are the same. Teams have collective blindspots and that's difficult to get around. We naturally tend to focus on what's in front of us, forgetting about realities outside our own influence.

UI testing isn't about replacing humans, but rather augmenting their abilities. We use automation to shore up our limitations, allowing us to focus on our strengths.

Developers waste their time testing on hundreds of different devices, when they could instead let a computer do that part of the work. Your QA team wastes its time running through the same test scenario week after week, when instead they could be thinking of new and undiscovered test cases.

UI automation isn't about replacing humans with machines, but rather giving us more freedom to work better than machines.

And let's not forget, UI testing requires a fair amount of work. It's not magic (although it's okay to convince management it is). This brings me to an important consideration...

There Are Always Drawbacks

How long do you think it takes to get a set of automated tests up and running? A week... maybe two?

Sure, if all you want to do is test that a page loads properly.

But websites are incredibly complex — the number of features we jam on a page grows each day.

Consider a "simple" homepage. Here are some things you'll want to test on it:

• Do all the parts look right on a laptop and desktop computer?
• Do all the parts look right on a tablet?
• Do all the parts look right on a phone?
• Does the site navigation work?
• Does the "need help" chatbox pop up after five seconds?
• Does the autocomplete in the site searchbar work?
• Does the hidden menu show after you click the menu icon?
• Does the carousel on the homepage rotate correctly?

Okay, I'll stop there. Hopefully you get my point that there's a lot to test even on a single page. A basic script that loads a page doesn't provide much reassurance.

So if you want to test all your functionality on all your pages, you're going to have to write a lot of code.

Covering all of that ground takes time. Time that could be spent on other, possibly more important, tasks.

And as you're writing test after test, the website your testing is going to keep changing. New features and fixes will be continuously introduced. The same feature will be tweaked again and again, causing your once-solid test suite to mysteriously start failing.

When the glorious day comes and you're "done" writing tests, you still have to maintain them. Now, there are ways to write tests to make them more maintainable, and we'll cover that throughout the examples, but there's no such thing as a future-proof test. You're always going to need to update it.

There's one more important point to consider.

While you'll breeze through some parts of test writing, expect to sink 80% of your time figuring out how to test that special 20% of your site's functionality. There are many areas of writing tests that aren't trivial. It's not as simple as calling the command to fill out a textbox and click the submit button.

You'll need to work with databases, integrate with third-party services and see if you can get commands to work in browsers with poor automation support. You're also going to run into instances where the way the website was coded just doesn't jibe with test automation.

Animations are a good example of that. How do you test that an animation works? You can fairly easily check the properties before and after an animation, but what about everything in between those two states?

Honestly, you'd need to do a screen recording of every frame of the animation, and compare that screen recording to a previous run to see if they match. I don't know about you, but that doesn't sound easy to me.

Simpler Sites for UI Testing

If you find yourself facing a complex site that would require major work to test properly, there are other options to gain some value without too much effort.

Instead of testing a fully working site, you may want to create a variation of your site that represents portions of the real thing. For example, pattern libraries are a popular option out there, especially for larger websites.

In case you're not familiar with them, pattern libraries are essentially living demos of the components that make up a website's interface. Mailchimp has a public pattern library if you'd like to see one in action (https://ux.mailchimp.com/patterns).

For instance, a pattern library may contain standalone versions of the following:

• Site layout components like the main navigation and site footer
• Components used across multiple pages, like buttons, form inputs, and tabs
• Style guidelines for simple page elements like links, headings, and lists

Pattern libraries are very helpful for teams, to document how the website should look and act. If you're tasked with adding a sortable table to your companies site, having a pattern library with a living example of one makes the job simple.

They're also useful for testers, as it gives us testable examples of individual components isolated from the complexity of the full website.

Skipping Automation is Sometimes the Best Option

Hopefully I haven't scared you away from UI test automation entirely. I only wanted to get you thinking about the whole picture.

And that picture should include saying, "Maybe we shouldn't write test automation for that... at least not yet."

Let's consider a few things...

New Features Aren't User Tested

Business is booming and your team is tasked with a brand-new feature idea that management thinks the customer will love. While it's tempting to say, "Yes, and let's write tests to go side-by-side with this new feature," it might not be the right time.

This brand-new feature has never seen the light of day, and the second a customer sees it there's going to be something they don't like about it. If a decision is made to rework the concept based on customer feedback, all those tests you've written become useless.

There's no point in writing a test if you haven't user-tested your site. So before you spend time writing assertions, ensure the assumptions about the user interactions are initially put to the test.

Time Writing Tests Takes Away from Writing Features

You're not paid to write tests; tests only serve the application they're testing. If an app is useless, tests won't help.

If you're working on a side project for a tool that no one uses, spending time writing tests takes away from time spent on more important tasks, like getting people to use your work.

Users don't care whether you have good unit tests. There's no difference between an unused tool and an unused unit tested tool.

Let yourself have untested code. Worry about that problem when it actually becomes one.

Tests Are Only Valuable When You Use Them

Don't write more tests when you're not using the ones you already have.

If you have 500 UI tests, but never put in the time to integrate them in your build and deployment process, you have 500 useless tests. Writing 500 more won't help.

Your tests should run on every code push. They should run before every deploy. Every developer on the team should see that the tests passed or failed.

If that's not true, you shouldn't be writing more tests, you should be taking advantage of the tests you already have.

Parts of the Site Might be Better Tested by People

Remember when I said tests shouldn't replace people, but rather augment their abilities. Well, in the scenario of testing an animation, we were stuck with a really complex solution. What if we just went with manual visual validation of the effect?

It's okay to have some parts of your site that are too complex for automation. Grab that low-hanging fruit and leave the stuff higher in the tree for a later time when you have a ladder.

Are Tests Worth It Then?

I've outlined the benefits and drawbacks of test automation, including reasons to entirely skip some of it.

So how do you ensure you're getting more benefits than drawbacks? Focus on these two goals:

• Ensure you're gaining value out of every test you write
• Ensure you're selling that value to those in charge

It's really easy to get caught up in automation, trying to cover every nook and cranny of the site. But if a feature of your site doesn't provide much value, how much less value would a test for that feature be?

The site login component breaking... that's bad. The site's About page having a typo... not such a big deal. Sure, we'd want to fix it, but it (hopefully) won't cost the company a lot of money.

By focusing on gaining and selling that value, you can keep yourself honest in your test writing, and focus on what's important: having a site that's running smoothly and providing value to the user.

Learn a Better Way To Test

There's a lot more to UI Test Automation than I've briefly covered here, including code!

In fact, this was just a short excerpt from The Web App Testing Guidebook. In the book, I cover what WebdriverIO can do and how you'll be using it day-to-day. I've built the examples around real-world scenarios that demonstrate how you would actually set things up. It's not just "what", but also "how to get there" with reasoning around every decision. Grab at copy today at LeanPub!

Header Photo by Rock'n Roll Monkey on Unsplash
Piano Robot Photo by Franck V. on Unsplash

Some pesky line of code causing your compilation problems? No worries, just throw // @ts-ignore on the line before and now your issues are all solved.

If you're feeling frisky, hack an entire file by adding /* tslint:disable */ to the top of it and now you don't need to worry about any TypeScript issues holding you back for that entire chunk of code.

2. the 'any' type

I don't like types. They're strict and restrictive and irritating and they get everywhere. So how do you eat your types and keep them too? Use the any type!

Say you want to create a new variable that'll probably be a string. Instead of typing it as such and restricting yourself from future changes, just type it as any and now you have free range to change things as necessary!

For example:

const myString : any = 'down with sand';

Want to change that to an integer lately? If you had strictly typed it, you'd have to update the code in two places. Using any, you don't have to worry about that! Genius!

3. Don't type variables

I know I just talked about using any to avoid strict typing, but I'm going to give you a pro tip: you don't have to define any typing at all!

That's right, even in TypeScript, you don't actually have to type any of your scripts! I'm a huge proponent of reducing code, and this goes right along with that best practice. Compare these two lines:

const myString : string = 'down with sand';
const myString = 'down with sand';

You can clearly see how the second line involves less complicated code than the first. Only a Java developer would prefer the former.

So next time your tempted to bloat your codebase with types, just don't. This one simple trick will save your bytes and bytes of code!

4. Don't define a function return type

If we don't have to type our variables, then why do we have to type our function returns? Answer: we do not! HAHA

It's a code smell to restrict your function to a single return type. Why? Because it's extra code!

Compare these two functions:

function sum (a: int, b: int) : int { return a + b; }
function sum (a, b) { return a + b; }

What's the difference between the two? An expert will happily tell you that the latter won't bind you into some pre-optimized state that can never be changed without breaking all your dependent programs. We don't want that now do we. Do we!?

5. Ensure 'strict' is always set to false in your tsconfig

There's one caveat to all of the above. You can't improve your code with these hot hacks if you've got 'strict' set to true in your tsconfig file.

That's why you should never, under any circumstances, ever, not even once, set strict to any value other than false.

Really, ask yourself, do you want to be strict? That's not fun, you Debbie Downer. Let people be free and let your code have the flexibility to live in a world not held down by arbitrary restrictions.

Conclusion

I hope these elite tricks help you in your job. TypeScript is here to stay for sure. But you don't have to let it control who you are or change your style. Follow these 5 simple hacks and you're set for instant success!

Photo by Sonny Ravesteijn on Unsplash

I'm tired of "Tools Every Developer in 2020 Must Know" articles.

They're mostly re-used content from the previous year and only serve as clickbait to get viewers to sites with questionable motivations. They're boring, unhelpful and undistinguishable from all the others out there.

Yes, we all know React is an important tool to know about. Give it a rest! Try instead to formulate a unique thought that might make others rethink the popular opinion they've heard time and time again.

So, how about an article not about "tools developers must know", but rather, "tools that changed what developers knew"?

In this list, I'm highlighting 25 JavaScript tools that I believe changed the industry over the past decade. All are/were popular, but it isn't ordered by popularity. Instead, we're looking at how revolutionary the ideas were, and how much they impact the JavaScript landscape.

Caveat: Knowing the "first publish date" of a tool is difficult, so I'm focused more on when the tool was popularized than when it was first published.

25. Istanbul

Honestly, it's harder to pick out #25 than it is #1. But I say Istanbul deserves to make the list over others for two reasons:

• It introduced code coverage to JavaScript, which started the decade with few automated testing tools out there. Istanbul promoted the testing discipline by making the lack of it much more visible.
• It's maintained that status as the "go-to code coverage" tool for the entire decade. Throughout the years, it's continued to be well-maintained and updated, which is a huge feat.

Despite my opinion that code coverage is over-emphasized in importance, it's a tough argument that Istanbul hasn't benefitted the industry through better test practices.

24. Prettier

I've used Prettier and I didn't like it. Kind of.

Okay, Prettier is extremely opinionated, and if that opinion is different from yours, you kind of just have to deal with it.

And I think that's the beauty of the tool. Bikeshedding is a real problem in dev teams, and tabs-vs-spaces arguments can quickly turn from fun to frustration when it's your daily life.

Prettier says "Stop!" to all of that. You install the tool, go with what it says, and it takes care of the rest. No options, but no frustrating "Code Style Review" meetings.

23. CypressIO

Developed in 2014, CypressIO has grown to become one of the most popular automated testing tools out there. That's not so revolutionary, until you realize they did it without supporting one of the most requested features out there (cross-browser testing).

The CypressIO team had a hunch that easy-to-write (and run) test automation was by far more important than any other feature. So that's what they focused on, to which they've had much success.

CypressIO is a reminder that many "needs" of customers are really just what they think they should want. You can be revolutionary by not doing something, allowing you to do a more important thing 10x better than before.

22. YUI3

You may not know YUI3. The library hasn't had a code commit since 2014. It's dead, Jim. Aside from that, its main competitor was jQuery, which held market-domination for its entire life.

But the folks at YUI3 were one of the first ambitious groups to create an entire library aimed at solving all of the pressing problems for front-end engineers.

They created a module loading system before module loading systems were cool.

They created a unit test framework before unit test frameworks were cool.

They created... well, the idea was that they tried to create everything. They took a look at the entire ecosystem of the front-end and said, "here's a solution."

All this while at a company (Yahoo!) which struggled year-over-year to get past the giant of Google.

YUI3 may not be remembered by most, but many developers learned many new ideas from it, myself included.

21. Ionic

Attempts to build "web-based mobile apps" existed before Ionic, but none seemed to capture the scope that Ionic has sought and achieved. Riding the furvor around Angular, Ionic offered devs like me a streamlined approach to developing mobile apps using the Angular ecosystem.

I'd say they've succeeded at their mission, as I was able to use Ionic to publish multiple tools to the Google Play and iOS App Store using their functionality. This may not seem like much, but it was important to me.

Ionic changed the landscape for front-end devs by giving us the functionality we needed to make it through the endless approval process involved in publishing a mobile app. And we were able to do it all using HTML, CSS and JS.

They've made a wealth of changes since I last used them a few years back, and the future for the tool looks brighter than ever. If you haven't checked out Ionic yet, take a look and see what you can do with a spare evening or two. It's really fun!

What's coming up!

As much as I'd love to finish covering the other 20 tools right now, I know it's best to split this into a multi-part series. Up next are tools 20-16, all of which focused on tooling/ecosystem improvements. Can you guess what they might be?

Photo by Todd Quackenbush on Unsplash

I ran into a bit of niche issue the other day that was driving me mad trying to figure out what was wrong.

I'm not sure how it should, or even if it should, be documented, but I figured it's worth mentioning here for anyone interested.

Basically, I have this HTML structure:

<div id="imageInput" class="imageComponent">
    <input type="file" />
    <div class="imageComponent">
        <input type="file" />
    </div>
</div>

I want to target that second file input, but I'm using a "component" so i have a "parent" element to go off of:

class ImagePicker () {
    constructor () {
        this.selector = '#imageInput'
    }

    get $origin () { return $(this.selector); }
    get $imageInput () { return this.$origin.$('.imageComponent input[type="file"]'); }
}

Strangely, that $imageInput element reference would fail as it selected the first input.
However, if I didn't use the $this.origin reference, and included the parent selector in my reference it works just fine:

get $imageInput () { return $('#imageInput .imageComponent input[type="file"]'); }

So that doesn't make any sense, right? this.$origin is equal to $('#imageInput'), so this.$origin.$('.imageComponent input[type="file"]') should be the same as $('#imageInput .imageComponent input[type="file"]')...

But it's not.

The reason is that the chained $ starts from the 'outside' of the origin element, so the .imageComponent selector matches the $origin element, not the child one, meaning the selector actually looks like $('#imageInput.imageComponent input[type="file"]') (i.e. no space between #imageInput and .imageComponent).

This functionality is normally unseen, as most HTML structures don't have a parent-child relationship that shares the same class name.

In the WebdriverIO docs, it says that when you chain selectors (e.g. $('.parent').$('.child'), "WebdriverIO starts the query from that element" (i.e. $('.parent')).

I read that as "it starts looking from inside the parent element", not, "it looks at the parent element first". I don't know how I'd word it though to clear that ambiguity, otherwise I'd submit a PR to update the docs 😄 I think it's just based on an internal assumption I've already made.

I was curious how the DOMs querySelector functionality behaves, and it turns out it's the same. document.querySelector('#imageInput').querySelector('.imageComponent input[type="file"]') has the same "issue". In fact, it has its own quirkiness: https://developer.mozilla.org/en-US/docs/Web/API/Element/querySelector#The_entire_hierarchy_counts

So what are my options?

An easy workaround is to change our element reference to include a second .imageComponent reference:

get $imageInput () { return this.$origin.$('.imageComponent .imageComponent input[type="file"]'); }

I really don't like that because honestly it's an ugly selector and oddly specific.

A better fix would be to edit the HTML, but that's not always possible.

One really interesting option is the :scope pseudo-class selector. It's not really useful in stylesheets, but when called on an element via querySelector, it matches that element. So $('#imageInput').$(':scope .imageComponent input[type="file"]') is the same as '$('#imageInput').$('#imageInput .imageComponent input[type="file"]')'.

That looks funny, so let's see how we'd use it back in our $imageInput element reference:

get $imageInput () { return this.$origin.$(':scope .imageComponent input[type="file"]'); }

One drawback of this approach is that :scope is relatively unknown, so anyone reading the code would have to look it up to understand why it's being used, so you'll probably want to leave a comment about it anytime you use this.

Overall, you likely won't run into this issue, but I could see it causing trouble on things like nested menus where classes are re-used in the nested elements. One of those things that you'd never know you need to know it, until you need to know it 😆

Header Photo by Shaojie on Unsplash

Remote working is considered the next revolution in the workplace, but I kind of hate it. What would cause me, who wrote an article titled "Why I Love Remote Working", to say that? Honesty.

There are many reasons to hate remote working, and I find it important to recognize those drawbacks. By being open about the issues remote working introduces, we can better equip ourselves to grow the practice.

Many companies are taking a "remote-only" approach. Because of this growing trend, I've been able to work remotely for over 4 years. In that time, I've faced many challenges that hopefully I can provide insight on.

Remote work is lonely business

The number one drawback of remote working is it's isolation. There are no random interactions during coffee breaks, no running to grab lunch with co-worker, and no friday afternoon nerf battles (unless you have kids at home).

While an introvert like myself finds solace in not being surrounded by people all day, it's unhealthy to be isolated from people for extended periods of time.

Solution

I believe that companies who support remote work should absolutely pay for a coffeeshop card and/or co-working space. This can easily be justified by comparing it to the cost of having to have office space. It's a small gesture that can have a big impact on someone's mental health. Companies should have an intrinsic motivation to take care of their employees, and this is a good step towards that.

Also, as a remote employee, make extra effort to be part of local tech groups. Also, join non-tech, hobby-related groups in town. Make up for that missing face-to-face time to help stay connected with humanity.

It can lead to a less active day

The joke about remote working is that your commute is the 10 steps from the kitchen to your desk. That's great, except when those are the only steps you're getting in all day.

In an office setting, you're walking to/from the parking lot, to/from the bathroom and jumping from meeting to meeting. While you can certainly still have a low-level of movement overall in the day, at least you're forced to walk some sort of extended distance.

Solution

Commit yourself to at least one physical activity in the middle of the workday. Don't feel guilty for spending time being active. It's your health!

Many companies offer gym memberships, so take advantage of that. Also, if your company has an on-site gym (several larger companies do), ask you manager for a similar benefit. Again, you're saving the company money in not having to provide office space for you, so they should be able to find it in the budget.

It can hurt your career (slower promotions, more difficult to break into management)

In some companies, there's definitely a glass ceiling for remote workers. While the company may be okay with Individual Contributors working remote, they want their management level employees to all be co-located. This means, as a remote worker, your promotions will always be limited at that company. It's frustrating, but it is also reality in many situations.

Another unfortunate truth is that if you're one of the only remote workers on your team, your work won't be as visible as those in the office. This means when it comes time for promotions, managers will be thinking about those they've seen in the office producing, not those out-of-sight doing quiet work in the background. Yes, this is a management problem (as they should be promoting/rewarding their most productive employees), but it's also your responsibility to work through.

Solution

Make sure you know where you want to be five years down the road. Don't rely on a big management mindset shift happening in regards to management being able to work remote. It may happen, but it's a big shift for many companies who are often afraid of that level of change.

Openly advocate for yourself to grow your career. Good advice in general, but absoutely necessary in this instance. I won't go into detail on what that means, because there are many great articles already written on it here and elsewhere on the internet.

Also, "brag" about your work. In chat rooms, post updates about things your working on and things that are causing trouble. Be visible there because you're not visible in the office.

More competition, less pay

Remote work is amazing because it gives you the freedom to work anywhere in the world. But this also means that anyone in the world can apply for the same job you want. Since cost-of-living differs dramatically across the globe, this means you may be competing with someone who can work for significantly less income than you. As a business, they're motivated to keep expenses low, and if someone can do just as effective job as you for half the rate, they're going to take that deal.

Solution

Don't be afraid to ask for the rate you need in order to live, but also consider using your freedom to move to a lower cost-of-living (COL) location. Give yourself a competitive advantage in this regard. There are some very beautiful, smaller cities across the globe. I recently moved from a large city to one a tenth of its size and I love it. The COL is about the same (it was a lower COL large city compared to NYC, etc), but the city feel so much more accessible. I'm able to bike almost anywhere around town and I never run into big-city traffic.

Also, in interviews, really push your soft-skills experience. This can be a major difference between you and other applicants, and many companies will happily pay extra on the bet that they're getting a more mature employee.

Finally, many companies in high COL areas are looking outside their city for employees who won't break the bank in salary. Watch out for those jobs, as they'll happily pay the same or higher than local companies, since it's still cheaper than hiring in their city.

Harder to get started in the morning and end in the evening

Without a commute and walk into an official office, it can be a little difficult to make that transition from waking up to being productive. And then when the end of the day comes, it can be tempting to just fix that one last bug. You don't see everyone else in the office leaving, so you forget that you should probably head out as well.

Solution

Find a morning routine that works. Pomodoro is a great option to get started. I do 10 minutes focused work with an optional 2 minute break. Many times I skip the break when I'm in a flow. But knowing that I'm only committing to 10 minutes, instead of that full 8-hour work day, makes all the difference in my getting started.

And at the end of the workday, remember that often, stepping away from the problem for the day can be the perfect solution. Just this morning I fixed a bug in five minutes that I was struggling with all yesterday afternoon. It was only by taking a break from the issue that I was able to break out of the unproductive debugging I was doing and see the code in a new light.

You're constantly reminded of all the work that needs to be done around the house

No one keeps their dirty laundry at the office (well, some co-workers do, but let's not talk about them). But at home, anytime you take a break, you're surrounded by all the house chores you need to get done. "Let me grab a quick snack oh yeah the sink is full of dirty dishes". "I'm going to take a quick break oh no the cat knocked over the magazine stack I might as well pick it up oh and who put that there, let me put that away really quick and I should really organize this drawer so it's easier to find things..."

You get the idea. Those are thoughts we have in an office (most of the time), since we're not surrounded by our never-ending chore list. Aside from watering a desk plant every now and then, most of the office maintenance is handed by a dedicated crew. That's not the truth at home and it can constantly take over what are supposed to your breaks.

And honestly, when facing a particularly tough situation at work, you might actually be motivated to do the dishes instead. Not that this isn't an effective "step back" strategy in some situations, you just shouldn't use it as a reason to avoid the job your paid to do.

Solution

Make room for an office space. Have dedicated snacks/water in your office. Have a good break area that isn't a constant reminder of all you need to get done around the house.

If you don't have that as an option, get out of your house to a nearby coffeeshop, hotel lobby, car dealership (pretend your car is being worked on while you pig out on their free coffee and donunts). Stop mixing your personal workspace with your professional workspace. It'll only cause you to stress out and raise your anxiety to unproductive levels.

I really do love remote working

Even with all of these reasons to hate it, remote working is definitely for me. There are always going to be drawbacks of certain working situations, and it's useless to deny them. If you work remotely, take a look at things that bother you and address them. Don't pretend they don't exist, like you're living in some make-believe world.

Remote workers, what things do you hate about the life? What solutions have you found to address them?

Also, this Oatmeal comic on the love/hate relationship with remote working is fantastic!

Photo credits (via Unsplash):
Fork Photo by Catt Liu
Workout Photo by Sven Mieke
City Photo by Monica Bourgeau
Cat Photo by Max Baskakov

There are times when I'm debugging a flakey test and I can't get it to fail. Yes, that's a real problem!

If you're working on a test that intermittently fails, it's useful to have a snippet that will run your test again and again until it fails. This is both to get to the state that it's failing easier, and to prove that most likely, the bug is fixed (if it doesn't fail after 10 test runs, chances are it's no longer an issue).

While you could just manually re-run your test again and again until it fails, what if you're lazy like me and want to automatically restart the test if it passed?

Thanks to an answer via Stack Overflow, you can do just this.

This shell function can be added to your .bashrc file (or whatever file your terminal program auto-loads on startup)

function untilfail() {
    while $@; do :; done
}

Then, after sourcing that file (or restarting your terminal), you can use it to run your WDIO script:

$ untilfail npx wdio --spec=failingTest.js

Want to just run it a set number of times? Here's a different function you can use:

function run() {
    number=$1
    shift
    for i in `seq $number`; do
      $@
    done
}

To use it to run wdio 5 times, pass in the number after the command:

$ run 5 npx wdio --spec=failingTest.js

Note that this second version won't stop running if there's a test failure. It'll keep running until you force it to stop, or it goes through the number of runs you requested.

Header Photo by Nathan Dumlao on Unsplash

I'm in an abusive relationship. My partner is a controlling, jealous, nightmare. There's a good chance you're involved in this too.

Of course, I'm talking about Twitter. The social media giant that has everyone up in arms about everything.

Why is it this way though? Why do we continue to go to that platform when it's so obviously toxic? Hmm, maybe I should explain why I think it's obviously toxic (in case it's not obvious to you):

Everything on twitter is public

This is the best/worst part of twitter. With everything being public, you can hear voices you never would have otherwise. You can meet people and form great connections.

If you're incredibly lucky.

If you're normal lucky or below, all you meet are people trying to find meaning in their life by arguing with strangers (I'm very guilty of this). A small percentage of these folks are assholes, who are mean just to be mean. Once you spot them, they're pretty easy to ignore.

But the majority of folks are smart and passionate about their cause. They see twitter as a way to make an impact and really believe that they can change lives through the medium. Which brings me to my next point:

Twitter isn't built for changing lives

The short-form communication setup of twitter is a double-edged sword. Limiting thoughts to 240-character sized chunks is fantastic for encouraging people to write. Your brain knows it doesn't have to commit to a five-page thesis; it only has to type out a few sentences.

So it becomes really easy to do that. You get to say something somewhat intelligent without the overwhelming effort of a fully-fleshed out defense. It's an incredibly easy way to feel a sense of purpose.

And with that comes the other side of the blade. Assertions on twitter will always, always be poorly constructed. No matter how well stated, you can't make a claim with ample evidence and counter-arguments pre-refuted and still fit it on twitter*.

Simply stating that last sentence took up half my allotted characters. So far, this blog post would take up 10 separate tweets.

* Yes, you can do the multi-tweet thread thing that people half-read and you don't know where to respond to so the conversation is completely lost and confusing and awful. Yes, you can do that, if you really want.

Everyone wants junk food

Twitter is junk food. It tastes so fucking good sometimes. So good you'll want to spend all day consuming it.

"Hey, that person agrees with me! This is going to feel so good to retweet! Ah, I hit that retweet button now everyone who reads this is going to finally be on my side. Oh I gotta do that again!"

"Hey, that person disagrees with me! But they have a flaw in their argument because all twitter arguments are too short to not have flaws! I'm going to point this obvious fact out to them and they agree with how completely wrong they are! Oh, they responded, saying obviously they didn't mention that counter-argument because it's well-refuted with another counter-argument. But they didn't mention this other thing because no one has room for that so I'm going to point it out and they'll agree with how completely wrong they are!"

It never works. The sentences and attention spans are always too short. We just fill ourselves up with this junk discussion and end the day feeling just as empty inside as when we started. Maybe the solution for the next day is to consume just a little more, better junk, then we'll be satisfied.

So twitter is toxic... now what?

Combine an excessively-public forum with woefully truncated statements and a bunch of people seeking some form of meaning in an overwhelmingly nihilistic world, and you get twitter.

It should be absolutely no surprise to anyone that this is a terrible, terrible place for public debates. Yet we find ourselves continuing to come back to it? Why?

Because junk food tastes so good and is a hell of a lot easier to make than a full-course meal.

'Hmm, i'm a little bit hungry... should I spend an hour cooking a healthy and delicious baked chicken parmesan dinner with mashed potatoes and fresh cooked green beans on the side, or should I just grab two oreo cookies, stuff them in my mouth and savor the short but ever sweet moment...'

Here are a few alternatives to twitter:

• Blog posts like these
• Longer-format online discussion boards
• Face-to-face conversations

I like blog posts. They're fun to write and I get to really think out ideas. But I can't write a blog post on my phone while I rock the baby to sleep. I also can't do it while in the waiting room for my next appointment or sitting on the can dropping a deuce. I can check twitter while doing those things though!

Also, for some reason, when writing a blog post, I want to double check everything. I treat the writing with much more respect and want to ensure I get it right. That adds yet another hour or two to the process, because there are just so many more words to adjust. I do the same thing with my tweets most of the time, but it's always limited to a sentence or two. Not three pages of text.

Online discussion boards are another good option, but they run into the same issue as with blog posts. There's just little time for this and you're still arguing with strangers on the internet.

Face-to-face conversations, even for introverts like me, are a great idea. But how do you find them or make time for them? It's difficult to get out of the house to go to a pub and talk about the [insert thing 1000 miles away] when you've got three kids who need dinner, baths, teeth-brushing, bedtime stories and to be coerced back to sleep at midnight.

All during that time, twitter is whispering in your ear "check me... check me... maybe you got a like! maybe someone retweeting that awesome thing you said! maybe you're tweet is going viral and you're missing out on all the fun!"

Then you check and you see either no responses, or if you're unlucky, some asshole has responded with a really poor counter-argument that would be so satisfying to refute. And you're hooked.

Where to go?

Despite all of this, twitter is useful. It can be hilariously funny. You can have good discussions with people you know on topics that aren't incendiary. That's what keeps me coming back.

But I'm wondering if that's worth the cost. The frustration at saying things and not being heard. At wanting to play devil's advocate, but getting called a bigot or hateful for doing so. There is no such thing as "for the sake of argument" on twitter. You're either for them or against them.

So for me, I want to write more on here. I want to fight the temptation to make a quick post on twitter, and commit to spending the time writing out full thoughts here. I end up investing the same amount of time, but here, I might actually get a return.

That's all. Now to post this to twitter to see if I can get any likes or retweets :)

Header Photo by Kevin Butz (hah) on Unsplash

"Honestly, does the client even care if the code is formatted or not?"

Have you ever had someone tell you this? Or maybe you're guilty of repeating that line. I know I am.

"Sure, I know standards are important, but we really don't have time to worry about that right now. The client just wants this feature shipped."

That's hard to argue against. The end result is what matters, especially when working for someone else. One the other hand, the idea of standards is to allow the team to ship faster (even if it takes an up-front investment). The client definitely cares about that.

So why are we unable to connect the dots between standards and the client's satisfaction? I have a theory.

Teams know standards are important, but they don't know how to make them happen. Typically, best practices becoming someone's "thing". Unit Testing is Allison's "thing". Code semantics is Bobby's "thing". Accessibility is Rachel's "thing".

But those "things" never become part of the collective mindset. There's no team ownership, no binding vision; just a bunch of things people are individually interested in. Managers encourage individual ownership, but withhold authority to implement the needed team-wide change.

An Adventure Starts

Let's think about what happens when individual "coding standard champions" are declared. Even when the team likes the idea, only the Champion makes the long-term changes needed to implement the solution.

Rather than addressing the lack of real buy-in from the group and the need for standards enforcement across the team, the Champion is encouraged to take individual accountability by management. This would look good on their mid-year review after all.

So the Champion goes off, fighting a huge battle to convert the codebase from the wicked ways of the past. They defeat the evil Tab dragon and travel back home with their Spaces safely in hand. It takes longer than expected, but feels good to have completed the work.

But what do they see when they arrive back home, weary from their travels?

Hundreds of new dragons hatching in the forms of poorly documented code and untested features. Why is no one dealing with these dragons before they become too big?! Oh, because it was the Champions thing. They're in charge of that.

So the Champion, still afraid to ask for real help, starts slaying these new dragons left and right. But then someone needs an outside resource and leaves the town gate open. New dragons come flooding in. Soon the Champion is overwhelmed with work, and fears another gate will be let open at any point in time, continuing the downward spiral.

So they put down their sword and the dragons take over. Someone asks months later, "Oh hey, weren't you fighting these things?" to which the Champion responds, "Yeah, but the client doesn't really care about dragons in our village, right? They just want to know the festival is going to happen and it's already a tight enough deadline."

Time Runs Out

Work continues until the festival time is near. There are dragons everywhere. They're eating the food. They're burning down the tents. Everyone is frantically running around trying to repair the chaos, but no one can get a handle on it.

The client is understandably upset. They hear talk of dragons ruining their festival and want to know why. To calm the client, promises are made to eradicate the dragons causing this chaos. But the festival must be moved back a couple weeks. The client, afraid to lose their investment, accepts the proposal.

Meetings are set up defining how best to slay these creatures. Champions are declared to deal with specific colors of dragons. Joe will take the green ones. Marcy will take the red. We'll meet in two weeks to see how things are going.

So Joe and Marcy start slaying dragons left and right. They're starting to get a handle on it; even teaming up in parts of town where there are a lot of both kind. They feel refreshed to have an ally in this fight and feel like they're making real progress.

Unknown to them though, the client is upset about the delay and wants a special tent installed as repayment. But Marcy is the only one who knows how to install that type of tent and she's already busy with very important work.

Without another rational choice, management decides to bring an outside worker in who specializes in all sorts of tents. They've promised to get this one installed in under two days. And they do. A couple days later the tent is up and Marcy and Joe have finished their work. All seems well.

Hidden In Plain Sight

The night before the big celebration, Marcy is walking around the various tents double checking tie downs and ensuring no dragons are lurking in dark corners. She comes to the special tent and notices something interesting about it. The beams holding the structure up are a different type of wood.

That's strange. Normally these poles come from a specific lumber mill, known for its quality. These must be different.

As she inspects closer, she notices strange holes in the wood. Then she notices it. The entire structure is swaying uneasily in the gentle breeze.

She immediately understands what's happening. The builder used cheap, rotted lumber — Lumber that's filled with wood-boring insects. These bugs are gnawing at the material, tearing it to shreds. She runs for helps as several adult beetles fly by her ear towards a neighboring tent.

She gathers the team in an emergency meeting. They decide they must hide the issue from the client. It's too late now to rebuild the structure; they can only hope it will survive the next few days of partying. They'll pull an all-nighter working to treat the bug infestation while the client sleeps.

A Terrible Success

It works. It works so well the client wants another party. In fact, the client wants parties like this every month. What a success for the team, right?

But they know the real truth. Their fixes worked, but they were unable to stop the bugs from spreading. The adult beetles surely laid eggs in every piece of wood throughout the fairgrounds. If they don't spend every day working to treat new infestations, the bugs will once again take over.

The damage done has required special scaffolding be put in to keep the tents sturdy. It's functional, but is delicate and difficult to adjust as the client's needs shift. They've already had to tell them that the jousting arena can't be upgraded because of "structural dependencies".

Joe, Marcy, and the rest of the team, once brave adventurers setting out to explore the landscape, are now confined to the city walls in a never-ending battle with the insects. Insects they had worked so hard at the start to keep out. They used the right materials sourced from the right people made in the right way.

But the client didn't care about that. The client just wanted a tent. And now Marcy has stopped caring as well. Why worry about using quality wood when it will just end up rotted anyway? This endless bug-squashing has worn her down. She's no longer motivated to start her day. Why should she? It's nothing new... just playing wack-a-mole against the insects.

New workers are brought in as she struggles to keep up. They also don't care about quality. They just need the steady income. They're satisfied squashing bugs. Every new tent for them means more job security. So they put up as many tents as they can, using whatever materials they find lying around.

Soon, the town becomes so filled with rotted wood that it becomes impossible to keep up the fight against the insects. Word is that the client doesn't like all the beetles buzzing around from square to square. A rumor has spread that the client is looking to move to a different town and a different company. A company that promises standards and quality craftsmanship; A company like this used one to be.

A New Start

In one last valiant effort, the team convinces the client to tear everything down and rebuild the city. They'll use the right materials this time. In fact, they'll invest in using the latest technology. Technology that comes with built-in pesticide. The beams are built to prevent insects from nesting, so it shouldn't be an issue.

The client is convinced and work begins.

Marcy, finding fresh motivation that she hasn't felt in years, sets up several meetings to help ensure standards are in place to keep this from ever happening again. She's excited to apply what she has learned to this new project. So many new ideas to try.

Her first: we must have quality control and follow strict guidelines in how work is done. People are excited, but a little skeptical. Won't that take extra time? Isn't this project big enough?

And honestly, does the client even care if the code is formatted or not?

Header photo credit: https://unsplash.com/photos/vVKbHNhu2ZU

I'm a front-end developer.

I love how visually appealing my job can be. I get to transform beautiful designs into fully-functioning websites.

But I hate how that beautifully working website can so easily turn into a mess with just a single code update.

I also hate how that mess can hide in the metaphorical corner for days or weeks until it's finally discovered by a customer or client.

While many teams validate their sites through a combination of manual and automated testing, design defects often sneak in due to the complexity of visual testing.

Manually checking the design of every page is difficult and time consuming, and humans aren't all that great at noticing small differences over large areas anyway.

To add on to that, most automated test libraries don't have the functionality needed to address visual testing at a large scale. While Selenium-based tools can capture screenshots of the page being tested, that's not nearly enough to run an real automated visual testing suite.

That's why Applitools is one of my favorite tools for visual testing. It comes with a suite of features that enable teams to capture and conduct visual reviews.

Recently, Applitools released a new SDK for WebdriverIO, which is my Selenium test library of choice.

Wait, what's WebdriverIO?

WebdriverIO is a JavaScript library for working with Webdriver, which is the "remote control" interface that runs behind the scenes of Selenium.

WebdriverIO is not the only JavaScript-based Webdriver interface out there, but I firmly believe it's the best.

There are a couple of reasons for this:

It's "front-end friendly"

Unlike a lot of Selenium tools out there, WebdriverIO is written entirely in JavaScript. Even the Selenium installation is done through an NPM module.

I always thought browser automation meant figuring out how to get some complex Java test suite running, which just never sounded appealing to me. As a front-end developer, my strength lies in JavaScript and CSS, and WebdriverIO encourages this.

Not only does WebdriverIO let me write in a language that I'm familiar with, it also integrates with the same testing tools that I use for unit tests (e.g. Mocha/Jasmine/CucumberJS).

I believe that Front-end developers should write tests for their code (both unit and functional). WebdriverIO makes it incredibly easy for them to do.

It Strives for Simplicity

The commands you use in your WebdriverIO tests are concise and common sense.

WebdriverIO eliminates the need to connect two parts together that are obviously meant for each other.

For example, if I want to click a button via a normal Selenium script, I would have to use two commands: One to get the element and another to click it.

Why? If I'm clicking something, it's obvious I'm going to need to identify it first.

WebdriverIO simplifies the 'click' command by accepting the element selector right in to the command, and does the work itself to create the two Webdriver actions needed.

That means instead of writing this:

driver.findElement(webdriver.By.id('btnG')).click();

I can just write this:

browser.click('#btnG')

That saves me from having to write an overly verbose test.

It has great service integration

One of the best benefits of WebdriverIO is it's built-in service layer. The layer allows anyone to add on to already great functionality that WebdriverIO provides.

For example, there's a service that manages starting up and shutting down a local Selenium server for you. There's another set of services that better integrate WebdriverIO with third-party Selenium services like Sauce Labs.

There's even a service to help you do visual testing.

Wait, why do I need Applitools then?

I'm a big fan of the visual regression service that I just mentioned; it's a great little service and can help individuals start down the path of visual testing, all without too much effort.

But it's missing a boat-load of features that Applitools offers.

First, it doesn't have a test dashboard, which is critical to managing screenshots across a team of people.

Second, it's not "smart". With Applitools, you can define different regions, letting you handle visual regression in different ways through those regions.

The visual regression service just doesn't contain that functionality. You're stuck fighting false positives in your testing, slowing you and your team down.

That's why I was excited when I heard you can combine WebdriverIO and Applitools. I knew the power of both, and would love to see them working together.

Okay, let's get going

The first step to getting this awesome approach in place is to write some WebdriverIO tests.

Assuming we're in a NodeJS project, we'll first install WebdriverIO by running the following command:

npm install webdriverio --save-dev

With WebdriverIO installed in our local project folder, we can run the next command:

npx wdio config

This command will ask WebdriverIO to help us configure the framework. It will ask a series of questions, to which I recorded my responses:

? Where do you want to execute your tests? **On my local machine**
? Which framework do you want to use? **mocha**
? Shall I install the framework adapter for you? **Yes**
? Where are your test specs located? **./test/specs/**/*.js**
? Which reporter do you want to use?  **dot - https://github.com/webdriverio/wdio-dot-reporter**
? Shall I install the reporter library for you? **Yes**
? Do you want to add a service to your test setup?  **selenium-standalone - https://github.com/webdriverio/wdio-selenium-standalone-service**
? Shall I install the services for you? **Yes**
? Level of logging verbosity **silent**
? In which directory should screenshots gets saved if a command fails? **./errorShots/**
? What is the base url? **https://applitools.com**

Upon answering that last question, WebdriverIO will install the tools and services you requested, then create a configuration file for you (named wdio.conf.js). This configuration file will be used in just a minute to help WebdriverIO run your test suite.

Our first test

Before we do run anything, we need to create a file containing a test to run. Here's an sample script used to load the Applitools Hello World page, then log out the title of said page.

describe('my first visual test', function () {
  it('should look visually perfect', function () {
    browser.url('./helloworld');

    const pageTitle = browser.getTitle();

    console.log(`Title of page is ${pageTitle}`)
  })
});

This file is saved in the ./test/specs directory, and I named it visual.js.

To execute our test, we'll go back to the command line, then run:

npx wdio

This will initialize WebdriverIO, which will search the current directory for a wdio.conf.js file. Upon finding that file, it will load the configuration, see where we told it to look for tests, find our new file and run it. The final output will look like:

 ~/Sites/wdio-applitools-demo$ npx wdio

Title of page is Applitools
․

1 passing (10.20s)

Adding in a little Applitools

While our test works, it doesn't provide a whole ton of value. All it does is log out the title of the page, which isn't that likely to contain a defect.

While we could write a series of tests validating any number of features, that would take a lot of effort to do. Instead, we can take advantage of the awesome functionality inside of Applitools to get a quick return on our work.

First, we need to install the Applitools WebdriverIO SDK. To do that, run:

npm install '@applitools/eyes.webdriverio' --save-dev

Then, we'll jump back into our test file and add a few things to finish our setup.

First, at the top of our file, we'll load Applitools and initialize it:

const {Eyes, Target} = require('@applitools/eyes.webdriverio');
const eyes = new Eyes();

To use the Eyes SDK, you need an API Key, which you can get by registering at the Applitools site. Once you have that, login and go to the Eyes admin tool. You will find the API using the following menu:

To use the key, add the following line (after the one initializing a new Eyes instance):

eyes.setApiKey('YOUR_API_KEY');

Now that we have Eyes set up, let's put it to use.

Since we're going to be doing some complex work, it's best to wrap all of our code in a try...catch block, allowing us to handle any network failures.

This is what our code looks like so far:

const {Eyes, Target} = require('@applitools/eyes.webdriverio');
const eyes = new Eyes();
eyes.setApiKey(process.env.APPLITOOLS_KEY);

describe('my first visual test', function () {
  it('should look visually perfect', async function () {
    browser.url('./helloworld');

    const pageTitle = browser.getTitle();

    console.log(`Title of page is ${pageTitle}`)

    const viewportSize = browser.getViewportSize();

    try {

    } finally {

    }
  })
});

Inside our try block, we're going to do five things:

• Open a new Eyes test
• Visually check the page
• Make a WebdriverIO call to alter the page
• Visually check the page again
• Close the test as it's complete

Here's what all of that looks like:

try {
	const viewportSize = browser.getViewportSize();
	
  await eyes.open(browser, 'Hello World!', 'My first Javascript test!', viewportSize);

  await eyes.check('Main Page', Target.window());

  browser.click('button');

  await eyes.check('Click!', Target.window());

  await eyes.close();
}

One important thing to notice is the use of the await keyword. await is a newer bit of functionality that helps us write cleaner tests by telling NodeJS to wait until the command has finished processing.

In order to use the await keyword, we need to define the function as async.

Thankfully that's easy to do.

In our it declaration, update it to include the async keyword:

it('should look visually perfect', async function () {

Almost ready

There's one last thing to do before running our newly updated test.

Because tests can break and networks can have issues, if we don't catch those outages, Applitools may show a failed test as "running" (since it was never told it was done running).

To avoid this, we're going to take advantage of that finally block to do some test cleanup. It will look like:

finally {
  await eyes.abortIfNotClosed();
}

With all of this in place, we finally have all the parts need to run an amazing automated visual test. We'll kick it off by running the npx wdio command again.

The output is going to look about the same, but if we go to our Applitools dashboard, we'll now see the results of our visual validation:

Capturing failures

The first time we ran our tests, Applitools created a set of baseline images to use for future runs.

If things go well, our next series of tests runs will match that set of baseline images, but we should ensure our tests fail if they don't.

Thankfully, WebdriverIO already handles this scenario, and we can make one small change to double-check that.

In our browser.url call, let's update the page to load a slightly different view:

browser.url('./helloworld?diff1');

This is a variation of the Hello World page, with a different number near the bottom. It's great example of a small visual change that may go undetected.

Running our tests again, we'll see our visual error be caught:

Title of page is Applitools
F

0 passing (14.90s)
1 failing

1) my first visual test should look visually perfect:
Test 'My first Javascript test!' of 'Hello World!' detected differences!. See details at: https://eyes.applitools.com/app/batches/00000251870526458572/00000251870526458181?accountId=st1DOzXoArpZcmkVYWMrt2u0G2A2gcBBAresB13CKDc110

We can go to the URL and see the culprit of our failure:

At this point, we can chose to update the baseline, create a smart region for it, or mark the test as a failure and update the team.

If you'd like to try this out without writing the code yourself, hop on over to the GitHub page, do a git clone then npm install and finally npx wdio.

Summary

Both Applitools and WebdriverIO are amazing tools that have so much more to offer than what I covered here. Hopefully this gets you going with both tools, allowing you to take advantage of the base functionality each one provides.

Header Photo Credit Josh Calabrese