End-To-End Tests with Content Blockers?

I was reading Eric Bailey’s recent piece Modern Health, frameworks, performance, and harm the other day. It’s excellent and you should go read it. The plot begins with Eric signing up for a site, meant to help him in a time of need, and the damn thing just spins:

Since I make digital experiences for a living, I immediately knew what happened. The signup user flow failed to transition me over to the onboarding user flow.

Totally unacceptable.

It made me think about why this happens. There are a ton of reasons. Network hiccup. Someone pushed a bug. The team didn’t test that particular configuration of browser/platform/version Eric is using. The last deployment didn’t decache a file like the developers thought it would. A corporate firewall interfered. There are infinite reasons, but few are an acceptable excuse, particularly for a healthcare website. There are loads of things developers can do to make a site more resilient, and it’s an unfortunate trend that they (I should say “we” and take some responsibility here) don’t.

But let me focus a little on my own experience with broken sites.

In my day-to-day browsing and doing things, if a website doesn’t work right, I find it extremely likely to be because my own content-blocking browser extensions are interfering. I use Ghostery and have it configured not to “trust” random sites (and origins), making me make that choice on my own. But I know tons of people like uBlock Origin and Adblock Plus as well. Use them, friends! It’s your goshdamn computer and advertising and tracking has long since jumped the shark on the web. Supporting things can be done on your own terms.

Just blocking a file shouldn’t totally wreck a website, but it often does! In JavaScript, that may be because the developers have written first-party JavaScript (which I’ll generally allow) that depends on third-party JavaScript (which I’ll generally block). Something like…

// https://tracking-website.com/tracking-script.js
window.trackThing = function() {
  // report data
}

// /script/index.js
function init() {
  trackThing("page loaded or something");
}
init();Code language: JavaScript (javascript)

If I block resources from tracking-website.com, now my first-party JavaScript is going to throw an error. JavaScript isn’t chill. If an error is thrown, it doesn’t execute more JavaScript further down in the file. If further down in that file is transitionToOnboarding(); — that ain’t gonna work.

So here’s an idea:

Run your end-to-end tests in browsers that have popular content blockers with default configs installed.

Doing so may uncover problems like this that stop your customers, and indeed people in need, from being stopped in their tracks.

Is anybody doing this? Cypress, Testim, Rainforest, etc… can you do this with your software?

---

UPDATE: Just today, I was on the website for a medication I started taking because they offer a discount card that is very substantial. I had to fill out a 4-page form. At the very end, I submitted it and… spinner forever. Guess what? I had to “trust” the site in Ghostery in order for it to go through. 🫠