Automated Testing – Blocking Tracking

One more on automated testing, if you allow me.

Yesterday evening (i.e. on July 17th, as this post is scheduled to go live on the 18th), I will hopefully have updated the test framework on github. There are two big changes in this new version, and those to have to be explained.

1. I swapped out PhantomJS against HtmlUnit, and
2. the tool can now block tracking whilst running tests.

The changes are related. I tried to work out blocking with PhantomJS and failed. I also saw a lot of weird PhantomJS behaviour when I upgraded my Raspberry Pi to Debian 9 ‘stretch’, so I decided to try something else. (This is sort of unfair, because stretch actually comes with PhantomJS, so you no longer have to load dubious binaries off the Internet, but hey.)

THIS HAS IMPLICATIONS FOR SOME OF YOUR TESTS! So read on!

HtmlUnit

Unlike PhantomJS, which is a standalone, if window-less browser, HtmlUnit is pure Java, meant to be used in Java programs or frameworks. It still behaves like a browser, in that it loads pages, makes a DOM, executes Javascript, and so on.

One thing that is different with HtmlUnit — and this you have to watch out for: when you ask it to inject and execute Javascript in a loaded page, it behaves differently than PhantomJS.

PhantomJS wraps your code into a function or something like that, which means your code must explicitly return a value, say: “return true;”

HtmlUnit, on the other hand, behaves exactly like the console in your browser. You hand it some code, it’ll execute it as-is. There is no returning anything.

For you, that means you have to change some of your tests. To be specific, you have to change all tests based on the following test runners:

1. genericJavascript,
2. genericJavascriptSetupAndCheckLater, and
3. genericJavascriptCascade

Rather than writing a script that ends with a “return” statement, write script that works in your console and evaluates to either true or false. Then simply copy that code into the test description.

Block Tracking

This feature was on my list for ages. I tried all sorts of silly things with PhantomJS, like adding a proxy to the framework. Then, one day, I accidentally discovered HtmlUnit, and all of a sudden, blocking (or filtering) was so easy.

So, here you go: the framework can now block HTTP GET requests — any HTTP GET requests — and you can specify patterns that should be blocked, filtered, cancelled, dropped, whatever you want to call it.

The great thing about that is that your test runs will no longer generate Analytics server calls if you block those, saving you money.

As a side-effect of this, you can block literally every and any request, including DTM or even the page you’d like to test. I expect you to not shoot yourself in your foot.

Some block patterns you can try:

• “/b/ss/” — will stop all Analytics calls
• “demdex.net” — will block calls to Audience Manager and the Marketing Cloud ID Service
• “mbox” — will kill off Target
• “adobedtm” — will suppress the loading of DTM

Testing what happens with DTM disabled? Sure can do!

On a personal level, the switch to HtmlUnit meant throwing away a fairly long and pretty involved article on proxies on the Raspberry Pi. While that obviously hurts, I’d say it’s a good thing.