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.
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!
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:
Rather than writing a script that ends with a “return” statement, write script that works in your console and evaluates to either
false. Then simply copy that code into the test description.
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.
7 thoughts on “Automated Testing – Blocking Tracking”
First I won’t block my test server calls, because i want to know if they fire (also a test).
Second if you selfhost DTM “adobedtm” won’t help you to block it. Better way would be “satelliteLib-“.
First – makes sense, although I still think the test should happen at lower level
Second – Erbsenzähler!
On what kind of lower level? And automated? And tested through different Browser Types?
And know in times where adblocker also blocking adobe urls, selfhosting is a way to go 😉
(yes i know some times i am pedantic)
I sort of see my tool as a “unit test” in the hand of dev. As such, I would expect to run tests on elements that dev can control, i.e. the page infrastructure (libraries, data layer, DOM elements, …)
IF you use it to tests Analytics-related stuff, then fair enough.
Self hosting is a highly recommended approach, at the same time we need to do negative testing by blocking satelliteLibs that way we are 100 % sure not impacting to actual application.
Tracking is second priority , always the number of priority is end user application.
HtmlUnit works for SPA applications ?
Your choice to abandon a full-scale headless browser like phantomjs for a browser simulator that can’t even render a page and take a screenshot is curious, to put it in flattering terms.
Even more curious is the reason, since from its very inception phantomjs has provided a method to abort outgoing requests before they leave the page, and that lets you achieve the “blocking” you seem to be describing.
Maybe you have come across a better harness for HtmlUnit than you’ve ever had for phantomjs, but it is quite likely that you will find your more advanced usability tests failing, or worse, not even being possible without an actual browser rendering engine.
I hear you.
Would you be willing and able to help?