L’une des plus grandes craintes que j’ai en tant qu’utilisateur de Google Tag Manager est une version cassée du site Web (ou de l’application) sur lequel j’ai déployé GTM. Bien trop souvent, le manque de bonnes pratiques de communication au sein d’une organisation conduit à la diffusion d’une version sans avoir testé en profondeur l’impact de cette version sur les solutions de suivi existantes.

Heureusement, il existe des moyens d’atténuer cela. Les précautions les plus importantes et les plus efficaces que vous puissiez prendre concernent le processus :

• Être actif dans le travail quotidien de l’équipe de développement.

• Introduisez « analytics » comme élément dans la définition de terminé de chaque version.

• Expliquez aux développeurs ce qu’est la couche de données et comment un bon déploiement GTM repose sur une couche de données stable.

En plus de cela, il existe des mesures techniques que vous pouvez utiliser pour éliminer davantage le risque de panne lorsqu’une nouvelle version est lancée dans la nature.

Tests unitaires doit être utilisé pour tester le code lui-même, en vérifiant qu’une entrée donnée produit toujours une sortie attendue. Lors des tests dataLayerceci est particulièrement important pour tous les objets que vous écrivez dans le modèle de page, car ils sont principalement pilotés par du code et ne dépendent pas de l’entrée de l’utilisateur.

Cependant, si vous n’exécutiez que des tests unitaires, il serait difficile de couvrir la variété de choses qui peuvent se produire dans le navigateur Web. C’est là que tests fonctionnels entrent en jeu, et ceux-ci seront au centre de cet article.

Avec les tests fonctionnels, vous exécutez en fait des tests sur une implémentation « réelle » du site Web. Cela signifie généralement qu’une version du site s’exécute sur localhost ou un environnement intermédiaire, puis utilise un navigateur “virtuel”, généralement déployé via un framework tel que Selenium, pour effectuer les étapes de test réelles.

Pour vous faire gagner du temps et des soucis, j’ai écrit un Open sourcesuite de tests fonctionnels autonome pour Google Tag Manager dataLayer appelé, imaginativement, gtm-datalayer-test.

Visitez le référentiel GitHub pour gtm-datalayer-test.

Le reste de ce guide explique comment la solution fonctionne.

Crédit

Premier crédit où le crédit est dû. La solution proposée dans cet article n’est en aucun cas révolutionnaire. L’utilisation de JSON pour contrôler les processus est très courante dans le monde du développement, et de nombreux frameworks de test prennent directement en charge la validation JSON pour les tests.

Une source d’inspiration directe pour cet article est le travail de Jan Exner avec une configuration TDD pour Adobe Analytics et DTM. Vous devriez jeter un coup d’œil au référentiel GitHub associé, où vous constaterez qu’il présente de nombreuses similitudes avec gtm-datalayer-test.

Comme cela arrive souvent, David Vallejo a été un partenaire de réflexion important pour la construction de la suite de tests. J’espère qu’il sera un contributeur régulier du projet !

Résumé en quelques secondes

Le pitch élévateur pour cette solution est le suivant :

gtm-datalayer-test est une solution de test fonctionnel pour le monde window.dataLayer file d’attente utilisée par Google Tag Manager. Les tests sont définis, exécutés et signalés à l’aide d’un fichier de configuration JSON spécial, qui valide par rapport à la dernière version de la norme JSON Schema. La solution peut être utilisée pour tester manuellement ou automatiquement si window.dataLayer a une structure attendue. Ceci est crucial, en particulier lorsque de nouvelles versions du site Web sont mises en ligne.

1. Mettez-le en marche

Tout d’abord, mettons les choses en marche. Avant de commencer, vous aurez besoin des éléments suivants :

1. NodeJS et NPM installés (ici)

2. Dernière version de Java (ici)

Une fois que vous les avez installés, vous devriez pouvoir exécuter les commandes suivantes dans votre terminal et obtenir un résultat valide pour chacune :

• java -version

• npm -v

• node -v

Une fois que vous les avez installés avec succès, vous pouvez obtenir gtm-datalayer-test opérationnel en exécutant les commandes suivantes. Exécutez la première commande (git clone) dans un répertoire où vous voulez que le gtm-datalayer-test répertoire du projet à établir.

1. git clone https://github.com/sahava/gtm-datalayer-test.git

2. cd gtm-datalayer-test

3. npm install

4. npm test

Lors de l’exécution de la commande finale, vous devriez voir quelque chose comme ceci :

Avec git clone ...vous avez extrait le code source de mon référentiel GitHub dans un répertoire nommé gtm-datalayer-testvers lequel vous avez ensuite navigué lors de la deuxième étape.

Ensuite, en courant npm install, npm (gestionnaire de packages pour Node) exécute toutes les dépendances répertoriées dans le package.json fichier et les installe localement dans le projet. Ceci est très important, car sans ces dépendances, le code lui-même est inutile.

Enfin, en courant npm testvous exécutez une script npm spécialement écrit pour ce projet. Il démarre d’abord un serveur Web simple, après quoi il exécute le dataLayer teste par rapport à un faux fichier index.html sur ce serveur. Enfin, il affiche les résultats du test dans la console.

Les chapitres suivants explorent chacune de ces étapes plus en détail.

2. Pile technologique

Node.js et npm vous offrent une multitude de modules prédéfinis avec lesquels travailler lors de la création de votre application Web. Je veux dire toi pouvait écrivez tout à partir de zéro, mais vous finirez par passer plus de temps, d’énergie et de cheveux à essayer de faire ce que les packages npm existants effectuent déjà beaucoup plus efficacement.

Ce projet utilise les technologies/dépendances/packages suivants :

• Node.js et npm en tant que technicien du serveur et gestionnaire de packages, respectivement.

• Java pour exécuter Selenium.

• ajv pour valider les schémas JSON de test personnalisés.

• chai comme bibliothèque d’assertions de test.

• chai-json-schema pour fournir des assertions personnalisées pour la validation du schéma JSON.

• chai-subset pour effectuer des vérifications de sous-ensemble par rapport à window.dataLayer.

• http-server pour agir comme un serveur HTTP léger à des fins de test.

• wdio en tant que lanceur de test, construit sur webdriverio.

• wdio-mocha-framework pour activer Mocha comme framework de test.

• wdio-phantomjs-service pour installer et exécuter le navigateur sans tête PhantomJS.

• wdio-selenium-standalone-service pour installer et exécuter le framework Selenium.

• wdio-spec-reporter (forké de l’original) en tant que reporter de test de spécification personnalisé.

• webdriverio pour exécuter Selenium via Node.js.

Vous n’avez pas besoin de savoir ce que font ces modules, mais en regardant la liste, une chose devrait ressortir : je suis à la recherche d’une solution autonome ici. Je sacrifie la personnalisation pour la facilité d’utilisation, mais même ce faisant, la modularité de gtm-datalayer-test n’a pas été compromis. Tous les packages ci-dessus contribuent au framework que j’ai construit, mais rien ne vous empêche d’extraire seulement quelques composants et de les intégrer dans votre propre suite de tests. En fait, je vous recommande fortement de le faire si vous avez déjà mis en place un framework de test fonctionnel !

Comme vous l’avez peut-être compris, le tout fonctionne sur JavaScript. Vous n’avez pas grand-chose à personnaliser, mais si vous souhaitez vous salir les mains, une certaine connaissance de JavaScript, en particulier d’ECMAScript 6 et de Node.js, est requise.

3. Comment ça marche

Chaque configuration de test comprend des pièces mobiles. Il y a le fichier de configuration wdio vous vous nourrissez wdioil y a le Spécification de test JavaScript lui-même, et puis il y a un configuration JSON vous utilisez pour définir vos attentes pour chaque test.

3.1. fichier de configuration wdio

Cette solution utilise WebdriverIO pour gérer une grande partie des démarches. WebdriverIO propose un tas de reliures nous pouvons utiliser avec les navigateurs virtuels exploités par Selenium. Avec Selenium, WebdriverIO nous donne tous les outils dont nous avons besoin pour définir, exécuter et rendre compte des tests que nous voulons exécuter sur une application ou une propriété Web donnée.

Pour rendre l’exécution de WebdriverIO aussi fluide que possible, nous utilisons un module appelé wdio pour lancer les tests. La grande chose à propos wdio est qu’il est très extensible et qu’il existe déjà de nombreux modules et plugins géniaux que nous pouvons utiliser avec lui pour faire ronronner notre configuration.

Les JavaScript de configuration wdio est fondamentalement ce qui dirige tout ce spectacle. Le JavaScript exporte un config objet, qui contient tous les paramètres que vous souhaitez définir pour le test. Cela inclut les pilotes de navigateur que vous souhaitez utiliser, les répertoires dans lesquels rechercher les fichiers de spécifications, le lanceur de test à utiliser, etc.

Vous pouvez trouver l’exemple de configuration, utilisé lors de l’exécution npm testdans le ./exemples répertoire, avec le nom exemples.conf.js. Voici à quoi ça ressemble :

const enhancedEcommerceSchema = require('../lib/enhancedEcommerceSchema.json') exports.config = {     specs: [         './examples/spec/basic_example.js'     ],     maxInstances: 10,     capabilities: [{         maxInstances: 5,         browserName: 'phantomjs',         'phantomjs.binary.path': './node_modules/phantomjs-prebuilt/bin/phantomjs'     }],     sync: true,     logLevel: 'silent',     coloredLogs: true,     bail: 0,     waitforTimeout: 10000,     connectionRetryTimeout: 90000,     connectionRetryCount: 3,     services: ['selenium-standalone'],     seleniumInstallArgs: {         version: '3.0.1'     },     seleniumArgs: {         version: '3.0.1'     },     framework: 'mocha',     reporters: ['spec'],     mochaOpts: {         ui: 'bdd'     },     before: function() {         const chai = require('chai');         chai.use(require('chai-json-schema'))         chai.use(require('chai-subset'))         chai.tv4.addSchema('/enhancedEcommerceSchema.json', enhancedEcommerceSchema)         global.expect = chai.expect         global.assert = chai.assert     } } 

Tout d’abord, assurez-vous de vérifier ici la gamme complète d’options que vous pouvez définir dans le fichier de configuration. C’est une bonne idée de vous familiariser avec les options disponibles, car vous devrez certainement en modifier certaines lors de l’extension de ces exemples à vos cas d’utilisation réels.

const enhancedEcommerceSchema = require('../lib/enhancedEcommerceSchema.json') 

Cette commande charge un schéma JSON de commerce électronique amélioré personnalisé auquel vous pouvez vous référer lorsque vous souhaitez tester si votre dataLayer contient des objets de commerce électronique amélioré valides. Il y a plus à ce sujet dans un chapitre ultérieur.

specs: [     './examples/spec/basic_example.js' ] 

Utilisez le specs mot-clé pour lister les emplacements avec les fichiers de test que vous voulez wdio à parcourir. Chaque fois que tu cours wdio sans le --spec paramètre de ligne de commande, il exécutera tous les tests répertoriés dans ce tableau.

Vous pouvez également utiliser des caractères génériques. Par exemple, tous mes tests sont stockés à divers endroits dans un répertoire nommé /spec/. Pour obtenir wdio pour exécuter tous les tests à l’intérieur, quel que soit le répertoire ou le nom de fichier, mon specs la configuration ressemble à ceci :

specs: [     './spec/**/*.js' ] 

Cela signifie que dans le directeur /spec/, parcourez tous les fichiers et répertoires pour tous les éléments qui ont le .js extension et les utiliser comme spécifications de test.

capabilities: [{     browserName: 'phantomjs' },{     browserName: 'chrome' }] 

C’est ici que vous définissez les instances de navigateur que vous souhaitez déclencher à chaque test. Fondamentalement, tout navigateur que vous listez ici sera lancé au démarrage de l’exécuteur de test, et les tests seront exécutés via chaque navigateur respectif. Chrome, Firefox et PhantomJS ont un support prêt à l’emploi dans gtm-datalayer-test.

D’ailleurs, PhantomJS est très populaire navigateur sans tête. Fondamentalement, c’est un navigateur sans interface utilisateur graphique. C’est donc une solution très légère et rapide pour exécuter vos tests. Cependant, avec chaque version majeure, vous devriez probablement également exécuter les tests via de “vrais” navigateurs.

framework: 'mocha', reporters: ['spec'] 

Ici, vous définissez ce que vous souhaitez utiliser Moka comme cadre de test, et spécification en tant que journaliste. Avec wdiovous pouvez aussi utiliser Jasmin ou alors Concombre au lieu de Moka. Vous avez également le choix entre plusieurs journalistes, ou vous pouvez créer le vôtre (assez simple, en fait). Pour plus de détails, voir ici pour les frameworks de test et ici pour les reporters.

before: function() {     const chai = require('chai');     chai.use(require('chai-json-schema'))     chai.use(require('chai-subset'))     chai.tv4.addSchema('/enhancedEcommerceSchema.json', enhancedEcommerceSchema)     global.expect = chai.expect     global.assert = chai.assert } 

Les before hook est exécuté avant que les spécifications de test ne soient exécutées. Dans ce crochet, je dis essentiellement wdio utiliser Chaï comme le affirmation bibliothèque de choix. Chai est une bibliothèque d’assertions très populaire, et elle est souvent utilisée avec Mocha pour fournir un langage plus expressif pour décrire vos tests. Vous pouvez utiliser la bibliothèque d’assertions de votre choix, ou vous pouvez utiliser la bibliothèque d’assertions Node.js par défaut, si vous le souhaitez.

Encore une fois, n’oubliez pas de lire le wdio Documentation. Il est très important de comprendre ce que vous pouvez personnaliser et comment. J’espère ajouter d’autres exemples au référentiel GitHub à l’avenir, mais je vous recommande tout de même de consulter la documentation.

3.2. Spécification de test JavaScript

Parce qu’il s’agit d’une solution autonome (du moins j’espère), vous n’avez pas vraiment besoin de toucher à la spécification de test JavaScript. Le tout est orchestré avec le wdio fichier de configuration et le fichier de configuration JSON.

Chaque spécification de test JavaScript exécute sa configuration JSON respective, exécutant un ensemble de tests par rapport au window.dataLayer objet sur n’importe quelle page qu’il visite.

Si vous souhaitez exécuter plusieurs spécifications, vous devrez copier à la fois le JavaScript de la spécification de test (par exemple basic_example.js) ainsi que la configuration JSON (par exemple basic_example.conf.json) dans le répertoire spec. Vous pouvez également avoir tous vos fichiers de spécifications dans un seul répertoire, si vous le souhaitez. Les wdio fichier de configuration regarde simplement à travers le /exemples/spec répertoire pour tous les fichiers de test JavaScript.

Je ne vais pas vous expliquer tout le dossier, mais il y a certaines choses que vous devriez savoir.

// Set the file in require() to point to this test's configuration JSON const dataLayerConf = require('./basic_example.conf.json') 

Si vous créez une nouvelle spécification de test, le nom du fichier JSON vers lequel vous pointez dans le require() La méthode doit faire référence à la configuration JSON que vous avez créée pour ce test.

La spécification de test passe par deux suites principales de tests :

1. Tests « génériques » pour window.dataLayeroù certaines clés doivent se trouver sur chaque page visitée par le test.

2. Configurations “spécifiques à la page”, où vous testez window.dataLayer sur chaque page donnée pour les paires clé-valeur spécifiques à la page.

Tous les rapports sont générés automatiquement en fonction de certaines valeurs dans la configuration JSON. Avant l’exécution du test, cependant, la configuration JSON elle-même est validée par rapport à ce que j’ai défini comme un schéma JSON valide pour ce projet particulier (vous pouvez le trouver dans /lib/validTestConfSchema.json). Si quelque chose manque ou est mal codé, le rapporteur de test s’arrêtera avec une erreur.

3.3. Fichier de configuration JSON

La configuration JSON est ce sur quoi repose tout le test. Tous les paramètres que vous fournissez régissent non seulement les pages que le test charge dans le navigateur virtuel, mais également ce que vous vous attendez à trouver dans window.dataLayer sur une page donnée.

Voici à quoi pourrait ressembler une configuration JSON entièrement chargée :

{     "baseUrl" : "https://www.simoahava.com",     "dataLayerName" : "dataLayer",     "multipleContainers" : true,     "dataLayer" : [{         "@json" : false,         "visitorLoginState" : "logged-out"     },{         "event" : {             "pattern" : "^gtm.dom$"         }     },{         "event" : {             "pattern" : "^gtm.load$"         }     }],     "page" : [{         "path" : "/gtm-tips/10-useful-css-selectors/",         "dataLayer" : [{             "@expect" : "dataLayer to have basic article variables",             "pageAttributes" : {                 "enum" : [["css-selectors", "google-tag-manager", "gtmtips"]]             },             "pageCategory" : {                 "enum": [["gtm-tips"]]             },             "pagePostType" : {                 "pattern" : "^post$"             },             "pagePostType2" : {                 "pattern": "^single-post$"             },             "postCountOnPage" : {                 "type" : "number"             },             "postCountTotal" : {                 "type" : "number"             }         },{             "@expect" : "dataLayer to have article impressions",             "event" : {                 "pattern": "^impressionsPushed$"             },             "ecommerce" : {                 "type" : "object",                 "properties" : {                     "impressions": {                         "$ref" : "/enhancedEcommerceSchema.json#/definitions/impressions"                     }                 },                 "required" : ["impressions"]             }         },{             "@expect" : "dataLayer to have clientId",             "event" : {                 "pattern" : "^trackerReady$"             },             "cid" : {                 "type" : "string",                 "pattern" : "[0-9]+\\.[0-9]+"             }         },{             "@expect" : "dataLayer to have product detail view",             "ecommerce" : {                 "type" : "object",                 "properties" : {                     "detail" : {                         "$ref" : "/enhancedEcommerceSchema.json#/definitions/detail"                     }                 },                 "required" : ["detail"]             }         }]     }] } 

Voici les principales touches avec lesquelles vous pouvez travailler :

• baseUrl (obligatoire) – une chaîne contenant le protocole complet, le domaine et le port du site où tous les tests sont exécutés dans cette spécification. Note! Laissez la barre oblique finale (https://www.simoahava.comNE PAS https://www.simoahava.com/).

• dataLayerName – si vous utilisez un autre nom pour le global dataLayer objet que “dataLayer”, n’oubliez pas de le spécifier ici. Sinon, vous pouvez laisser cela de côté (le test par défaut est dataLayer).

• multipleContainers – réglez ceci sur true si vous avez plusieurs conteneurs sur la page. Sinon, laissez cela de côté.

En plus de cela, il y a dataLayerqui est un tableau d’objets que vous vous attendez à trouver sur chaque page visitée par le test (configuration générique).

Il y a aussi pageoù vous spécifiez chaque page que vous souhaitez que le test visite, avec toutes les configurations dataLayer spécifiques à la page définies à l’intérieur.

Vous trouverez plus d’informations sur le fichier de configuration dans le chapitre suivant.

4.Configuration JSON

Reprenant là où nous nous sommes arrêtés dans le chapitre précédent, concentrons-nous sur les deux tableaux de configuration importants que nous n’avons pas encore couverts : dataLayer[] et page[].

4.1. Couche de données générique

Les dataLayer La clé à la racine de la configuration JSON est l’endroit où vous répertoriez les objets que vous vous attendez à trouver sur chaque page visitée par le test. Ce sont des clés dites « génériques ». Donc, disons que vous vous attendez à trouver un objet qui contient la paire clé-valeur "event" : "gtm.dom"ainsi qu’un objet facultatif où leur clé est "visitorLoginState" dont la valeur est n’importe quelle chaîne, voici à quoi pourrait ressembler l’objet générique :

{     ...     dataLayer : [{         "@json" : false,         "event" : "gtm.dom"     },{         "visitorLoginState" : {             "@rootRequired" : false,             "type" : "string"         }     }]     ... }

Voyons ce que signifient ces touches.

@json est une configuration spéciale qui ne peut avoir que false évaluer. Toute autre valeur et le schéma ne seront pas validés. Si un dataLayer l’objet a cette clé dans la configuration, cela signifie que toutes les paires clé-valeur dans cet objet seront recherchées textuellement au sein du monde window.dataLayer chose. Autrement dit, si window.dataLayer n’a pas au moins un objet avec le exact paire clé-valeur "event" : "gtm.dom"le test échouera.

Vous pouvez ainsi utiliser le "@json" : false réglage pour exécuter simple contrôles de sous-ensemble. Vous pouvez définir des objets complexes, des tableaux ou tout type de données disponible, mais ils doivent être trouvés dans ce format exact dans window.dataLayer. Cette contrôle de sous-ensemble est un excellent moyen de tester les paires clé-valeur qui, selon vous, seront immuables d’une version à l’autre.

Si vous ne pas fournir le @json clé, le test sera validé par rapport à la logique du schéma JSON. JSON Schema est une norme (ébauche) utilisée pour décrire JSON…