What to Test

I think we can safely say that I have thoroughly gutted DTM by now, and that whatever else I unearth from it now won’t be a pretty sight.

That must mean it is time to stop writing about integration, code, and dirty tricks, and instead to wag my finger at you whilst mumbling dark prophecies or invoking utter despair or some-such.

Don’t worry, there are plenty more implementation articles in the queue right now. I’m only pushing them back a bit whilst I ramble on about other things.

Testing

There is only one topic that I rate as highly as DTM these days: testing, automated testing.

I have written a couple of articles about the subject, and I am likely going to discuss my ideas at the Adobe Summit in London in May. While I was sorting through what I had, though, I realised that so far I had not really done my job.

My job on this blog is to help you, the developer, make your job easier.

So when I talk about testing, you probably don’t want to hear me say things like “automated tests … good”, or “wow, selenium!” What you actually need is guidance on how to make tests that help. Right?

What I guess must be your wish is my command! Here’s a short and still relatively high-level list of things you should test along with my ideas on how to do that.

Data Elements

Data Elements carry information into the Analytics tool. They are sort of an abstraction on top of the site, data layer and all. That makes them a great candidate to test!

We want to know two things for each page or template on your site:

1. does the Data Element called “x” exist? Does it have a value?
2. is it the correct value?

This is incredibly easy to test! All you need to do is ask DTM for the value, then compare.

The Javascript for getting the value is simple:

var result = _satellite.getVar("x");

For most Data Elements, this test can be run at any point after the page has loaded. Using Selenium and WebDriver, you could do it like this:

	private String getValueOfDataElement(String dataElementName) {
		Object result = js.executeScript("return _satellite.getVar('" + dataElementName + "');");
		return (String) result;
	}

Since your site is likely to have a lot of pages, I suggest you stick with templates instead, testing one page per template. Otherwise just cataloging and maintaining the list of tests for all Data Elements will be a full-time job.

So, run one test for the product detail page using a randomly picked product (the same every time, of course), one for the search results page (using the same search term), one for the home page, and so on etcpp.

Page Load Rules

For Page Load Rules, we want to see whether they have fired or not on a given page. If you’re paranoid, you might want to test whether they exist.

The easiest way to find out whether a PLR fired is to get DTM’s log and sift through it for messages reading “Rule x fired.” until you find the one you’re looking for or run out of lines.

How do you get the log? With Selenium and WebDriver, you can do this:

ArrayList<ArrayList<String>> logEntries = (ArrayList<ArrayList<String>>) ((JavascriptExecutor) driver).executeScript("return _satellite.Logger.getHistory()");
List<String> rulesThatFired = new ArrayList<String>();

Again, cataloging which Rule should fire on which page could be a certain effort. And again, I suggest you pick sample pages and test on those.

Direct-call Rules

DCRs can be called directly from Javascript, and that’s about it. So what would we test?

Well, I say we should test for their existence!

In Javascript, you can obtain the list of DCRs like so:

var dcrs = _satellite.directCallRules;

Pull that back into your test framework and search it for the DCR you expect to find. Bingo.

That same technique works for PLRs and EBRs, too (pull _satellite.pageLoadRules or _satellite.rules).

Event-based Rules

EBRs, by definition, are triggered by some event. In order to test them, we therefore have to trigger that very event in the test.

For the example of a product details page with an “Add to Cart” button, the test would start with the test framework loading the page, then simulating a click on that very button. After that, it would assert that the rule has fired.

The mechanism here is exactly the same as for PLRs, but managing the tests obviously now includes managing triggers, too.

As you might have gathered, I like that! It means that there has to be some sort of an agreement between you and your friendly marketer about what triggers she deems important. Formalising such a thing is good!

Data Element for EBRs

When EBRs fire, they are likely going to use some Data Elements, too. And it is likely that those DEs only have values at the time the EBR fires. Which means we can’t test these DEs on page load with the rest. It makes sense to test these DEs along with the EBR they belong to.

Since we already know how to test the value of a DE, there’s really nothing new to say here. Just test the DE after you triggered the EBR.

Data Layer

What about the data layer? You have a CEDDL-compatible data layer, right? You should test that, no? Oh, yes, you should!

Since the data layer is ideally just a Javascript variable named “digitalData”, testing it is as simple as getting the individual elements of that object and running a bunch of assertions.

On a product page, for example, the relevant part of the data layer might look like this:

var digitalData = {
	product: [{
		productInfo:{
			productName: "RaspBerry PI 3",
			sku: "raspi003"},
		category:{
			primaryCategory: "Computers"},
		attributes:{
			availability: "in stock"
		}
	}]
};

For our purposes, we’d want to test the values of the “productName”, “sku”, and “primaryCategory” elements, and make sure that the “availability” element exists.

TDD – Always more

I feel I must restate one thing: this is NOT testing for your friendly marketer!

The audience of all the tests I outline here is not her, it is you, the developer. The tests are not designed to reassure her, or show her how good the data currently is. The tests are purely designed for your deployment or CI processes, simply there so you know when your development has potentially upset something that will break Analytics.

There are existing tools in the market that do the testing for marketers. There are people who have blogged about how to test tracking itself.

But I think the disconnect between what you are doing versus what your friendly marketer is doing is a bigger problem, sort of the underlying issue. It is also a communications issue, and defining the interface more explicitly can only help.

My hope is that these tests can help define the interface, and maybe even help make it stable enough that everyone can concentrate on their work more successfully.

Questions?

With all of these out of the way, my question to you, the developer, is: do you have any questions?

Is this all you need? What else would you want us, marketing or analytics, to provide?

No?

Then what are you waiting for?