One of the biggest fears I have as a Google Tag Manager<\/a> user is a broken release of the website (or app) on which I have deployed GTM. Far too often, lack of proper communication practices within an organization lead to a release being pushed out without thoroughly testing how this release impacts any existing tracking solutions.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n Luckily there are ways to mitigate this. The most significant and impactful precautions you can take are all about process<\/a>:<\/p>\n Be active in the daily development team work.<\/p>\n<\/li>\n Introduce \u201canalytics\u201d as an item in the definition of done<\/a> of each release.<\/p>\n<\/li>\n Educate the developers on what Data Layer is<\/a> and how a proper GTM deployment hinges on a stable Data Layer.<\/p>\n<\/li>\n<\/ul>\n In addition to these, there are technical measures you can employ to further eliminate the risk of things breaking down when a new release is pushed into the wild.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n Unit tests<\/strong> should be used to test the code itself, verifying that a given input always produces an expected output. When testing However, if you only ran unit tests it would be difficult to cover the variety of things that can happen in the web browser. That\u2019s where functional tests<\/strong> come into play, and those will be the focus of this article.<\/p>\n With functional tests, you are actually running tests on a \u201creal\u201d implementation of the website. Typically this means having a version of the site running on localhost or a staging environment, and then using a \u201cvirtual\u201d browser, typically deployed via a framework such as Selenium<\/a>, to perform the actual test steps.<\/p>\n To save you time and trouble, I have written an open-source<\/strong>, self-contained functional test suite for Google Tag Manager\u2019s <\/p>\n <\/a><\/p>\n<\/div>\n Visit the GitHub repo for gtm-datalayer-test<\/a>.<\/p>\n The rest of this guide covers how the solution works.<\/p>\n \n \n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n <\/span><\/p>\n First credit where credit is due. The solution proposed in this article isn\u2019t ground-breaking in any way, shape or form. Using JSON to control processes is very common in the development world, and there are many test frameworks that directly support JSON validation for tests.<\/p>\n A direct inspiration to this article is Jan Exner<\/a>\u2019s work with a TDD setup for Adobe Analytics and DTM. You should take a look at the related GitHub repo<\/a>, where you\u2019ll find that it has many similarities to gtm-datalayer-test.<\/p>\n As often happens, David Vallejo\u2019s<\/a> been an important brainstorming partner for building the test suite. I hope he will be a regular contributor to the project!<\/p>\n The elevator pitch for this solution is this:<\/p>\n gtm-datalayer-test is a functional testing solution for the global First, let\u2019s get things up and running. Before you start, you will need the following things:<\/p>\n NodeJS and NPM installed (here<\/a>)<\/p>\n<\/li>\n Latest version of Java (here<\/a>)<\/p>\n<\/li>\n<\/ol>\n Once you have these installed, you should be able to run the following commands in your terminal and get a valid result for each:<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n Once you\u2019ve installed these successfully, you can get gtm-datalayer-test<\/strong> up and running by executing the following commands. Run the first command ( When running the final command, you should see something like this:<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n With Next, by running Finally, by running The following chapters explore each of these steps in more detail.<\/p>\n Node.js and npm give you a wealth of pre-built modules to work with when building your web application. I mean, you could<\/em> write everything from scratch, but you\u2019ll end up spending more time, energy, and hair trying to do the stuff that existing npm packages already perform much more efficiently.<\/p>\n This project uses the following technologies \/ dependencies \/ packages:<\/p>\n You don\u2019t have to know what these modules do, but by looking at the list, one thing should jump out: I\u2019m gunning for a self-contained solution here. I\u2019m sacrificing customization for ease of use, but even in doing so the modularity of gtm-datalayer-test<\/strong> hasn\u2019t been compromised. All the packages above contribute to the framework I have built, but nothing\u2019s stopping you from extracting just some components and integrating them into your own test suite. In fact, I strongly recommend you do so if you already have a functional testing framework set up!<\/p>\n As you might have gathered, the whole thing runs on JavaScript. There\u2019s not much you need to customize, but if you do wish to get your hands dirty, some knowledge of JavaScript, especially ECMAScript 6<\/a> and Node.js<\/a>, is required.<\/p>\n Each test setup comprises some moving parts. There\u2019s the wdio configuration file<\/strong> you feed to wdio<\/strong>, there\u2019s the JavaScript test spec<\/strong> itself, and then there\u2019s a configuration JSON<\/strong> you use to define your expectations for each test.<\/p>\n This solution uses WebdriverIO<\/a> to manage much of the legwork. WebdriverIO offers a bunch of bindings<\/em> we can use together with the virtual browsers operated by Selenium. Together with Selenium, WebdriverIO gives us all the tools we need to define, execute, and report on tests we want to run on any given application or web property.<\/p>\n To make running WebdriverIO as smooth as possible, we use a module called wdio<\/strong> to run the tests. The great thing about wdio<\/strong> is that it\u2019s very extendable, and there are already lots of great modules and plugins we can use with it to make our setup purr.<\/p>\n The wdio configuration JavaScript<\/strong> is basically what runs this whole show. The JavaScript exports a You can find the example configuration, used when running First, be sure to check here<\/a> for the full range of options you can set in the configuration file. It\u2019s a good idea to familiarize yourself with the available options, since you\u2019ll definitely need to modify some of them when extending these examples to your actual use cases.<\/p>\n This command loads a custom Enhanced Ecommerce<\/a> JSON Schema which you can refer to when you want to test if your Use the You can use wildcards, too. For example, all my tests are stored in various places within a directory named \/spec\/<\/strong>. To get wdio<\/strong> to run through all tests within, regardless of directory or file name, my This means that in the director \/spec\/, look through all the files and directories for any items that have the .js<\/strong> extension, and use them as test specifications.<\/p>\n This is where you define the browser instances you want to fire with each test. Basically, any browser you list here will be launched when the test runner starts, and the tests will be run through each respective browser. Chrome, Firefox and PhantomJS have support out of the box in gtm-datalayer-test.<\/p>\n By the way, PhantomJS<\/strong> is a very popular headless browser<\/em>. Basically, it\u2019s a browser without a graphical user interface. It\u2019s thus a very lightweight, quick solution for running your tests on. However, with every major release you should probably run the tests through \u201creal\u201d browsers, too.<\/p>\n Here you define that you want to use Mocha<\/strong> as the test framework, and spec<\/strong> as the reporter. With wdio<\/strong>, you can also use Jasmine<\/strong> or Cucumber<\/strong> instead of Mocha. You also have a bunch of reporters to choose from, or you can build your own (quite simple, actually). For more details, see here for test frameworks<\/a> and here for reporters<\/a>.<\/p>\n The ![\"run](\"https:\/\/www.simoahava.com\/images\/2017\/01\/dataLayer-undefined.jpg#ZgotmplZ\")
<\/p>\n\n
![\"Data](\"https:\/\/www.simoahava.com\/images\/2017\/01\/datalayer-assert-example.jpg#ZgotmplZ\")
<\/p>\ndataLayer<\/code>, this is especially important for any objects you write into the page template, as they are mostly code-driven and do not depend on user input.<\/p>\ndataLayer<\/code> called, imaginatively, gtm-datalayer-test<\/strong>.<\/p>\n![\"gtm-datalayer-test](\"https:\/\/www.simoahava.com\/images\/2017\/01\/gtm-datalayer-test.jpg#ZgotmplZ\")
<\/p>\n
\n X<\/span><\/p>\n
\n The Simmer Newsletter<\/strong>\n <\/p>\nCredit<\/h2>\n
Elevator pitch<\/h2>\n
\n
window.dataLayer<\/code> queue used by Google Tag Manager. Tests are defined, executed, and reported using a special JSON configuration file, which validates against the latest draft of the JSON Schema<\/a> standard. The solution can be used to manually or automatically test if window.dataLayer<\/code> has an expected structure. This is crucial especially when new releases of the website are pushed live.<\/p>\n<\/blockquote>\n1. Get it up and running<\/h2>\n
\n
\n
java -version<\/code><\/p>\n<\/li>\nnpm -v<\/code><\/p>\n<\/li>\nnode -v<\/code><\/p>\n<\/li>\n<\/ul>\n![\"Commands](\"https:\/\/www.simoahava.com\/images\/2017\/01\/commands.jpg#ZgotmplZ\")
<\/p>\ngit clone<\/code>) in a directory where you want the gtm-datalayer-test<\/strong> project directory to be established.<\/p>\n\n
git clone https:\/\/github.com\/sahava\/gtm-datalayer-test.git<\/code><\/p>\n<\/li>\ncd gtm-datalayer-test<\/code><\/p>\n<\/li>\nnpm install<\/code><\/p>\n<\/li>\nnpm test<\/code><\/p>\n<\/li>\n<\/ol>\n![\"after](\"https:\/\/www.simoahava.com\/images\/2017\/01\/npm-test.jpg#ZgotmplZ\")
<\/p>\ngit clone ...<\/code>, you pulled the source code from my GitHub repo<\/a> into a directory named gtm-datalayer-test<\/strong>, which is where you then navigated to in the second step.<\/p>\nnpm install<\/code>, npm<\/strong> (package manager for Node) runs through all the dependencies listed in the package.json<\/strong> file, and installs them locally to the project. This is very important, as without these dependencies the code itself is useless.<\/p>\nnpm test<\/code>, you are executing an npm script<\/em> specifically written for this project. It first starts a simple web server, after which it runs the automated dataLayer<\/code> tests against a mock index.html file on that server. Finally, it outputs the results of the test into the console.<\/p>\n2. Technology stack<\/h2>\n
3. How it works<\/h2>\n
3.1. wdio configuration file<\/h3>\n
config<\/code> object, which holds all the settings you want to define for the test. This includes what browser drivers you want to use, in which directories to look for spec files, what test runner to use, etc.<\/p>\nnpm test<\/code>, in the .\/examples<\/strong> directory, with the name examples.conf.js<\/strong>. Here\u2019s what it looks like:<\/p>\nconst<\/span> enhancedEcommerceSchema = require('..\/lib\/enhancedEcommerceSchema.json'<\/span>)\nexports.config = {\n specs: [\n '.\/examples\/spec\/basic_example.js'<\/span>\n ],\n maxInstances: 10<\/span>,\n capabilities: [{\n maxInstances: 5<\/span>,\n browserName: 'phantomjs'<\/span>,\n 'phantomjs.binary.path'<\/span>: '.\/node_modules\/phantomjs-prebuilt\/bin\/phantomjs'<\/span>\n }],\n sync: true<\/span>,\n logLevel: 'silent'<\/span>,\n coloredLogs: true<\/span>,\n bail: 0<\/span>,\n waitforTimeout: 10000<\/span>,\n connectionRetryTimeout: 90000<\/span>,\n connectionRetryCount: 3<\/span>,\n services: ['selenium-standalone'<\/span>],\n seleniumInstallArgs: {\n version: '3.0.1'<\/span>\n },\n seleniumArgs: {\n version: '3.0.1'<\/span>\n },\n framework: 'mocha'<\/span>,\n reporters: ['spec'<\/span>],\n mochaOpts: {\n ui: 'bdd'<\/span>\n },\n before: function<\/span>() {\n const<\/span> chai = require('chai'<\/span>);\n chai.use(require('chai-json-schema'<\/span>))\n chai.use(require('chai-subset'<\/span>))\n chai.tv4.addSchema('\/enhancedEcommerceSchema.json'<\/span>, enhancedEcommerceSchema)\n global.expect = chai.expect\n global.assert = chai.assert\n }\n}\n<\/code><\/pre>\n<\/div>\nconst<\/span> enhancedEcommerceSchema = require('..\/lib\/enhancedEcommerceSchema.json'<\/span>)\n<\/code><\/pre>\n<\/div>\ndataLayer<\/code> has valid Enhanced Ecommerce objects within. There\u2019s more on this in a later chapter.<\/p>\nspecs: [\n '.\/examples\/spec\/basic_example.js'<\/span>\n]\n<\/code><\/pre>\n<\/div>\nspecs<\/code> keyword to list the locations with test files you want wdio<\/strong> to run through. Whenever you run wdio<\/strong> without the --spec<\/code> command-line parameter, it will run through all the tests listed in this array.<\/p>\nspecs<\/code> configuration looks like this:<\/p>\nspecs: [\n '.\/spec\/**\/*.js'<\/span>\n]\n<\/code><\/pre>\n<\/div>\ncapabilities: [{\n browserName: 'phantomjs'<\/span>\n},{\n browserName: 'chrome'<\/span>\n}]\n<\/code><\/pre>\n<\/div>\nframework: 'mocha'<\/span>,\nreporters: ['spec'<\/span>]\n<\/code><\/pre>\n<\/div>\nbefore: function<\/span>() {\n const<\/span> chai = require('chai'<\/span>);\n chai.use(require('chai-json-schema'<\/span>))\n chai.use(require('chai-subset'<\/span>))\n chai.tv4.addSchema('\/enhancedEcommerceSchema.json'<\/span>, enhancedEcommerceSchema)\n global.expect = chai.expect\n global.assert = chai.assert\n}\n<\/code><\/pre>\n<\/div>\nbefore<\/code> hook is executed before any test specs are run. In this hook, I basically tell wdio<\/strong> to use Chai<\/strong> as the assertion<\/em> library of choice. Chai<\/a> is a very popular assertion library, and it\u2019s often used together with Mocha to provide a more expressive language for describing your tests. You can use any assertion library you want, or you can use the default Node.js assertion library<\/a>, if you wish.<\/p>\n