 C'est vrai que vous m'épattez un peu parce qu'il y a un titre de conférence qui n'est pas très sexy là et vous êtes quand même venu plutôt que vous mettez en avance pour accéder au buffet donc je vous remercie. Est-ce que vous êtes développeurs ? Est-ce qu'il y a des développeurs dans la salle ? Des gens qui font de la programmation ? Ouais, ouais, quand même. J'avais bien prévu le titre. Bon, pour ceux qui ne le sont pas, oui, vous pouvez rester. Vous risquez de vous ennuyer un peu. En fait, vous risquez tous de vous ennuyer parce que j'ai prévu de pinayer sur le jargon et de faire des exemples un peu techniques un peu chiants mais si vous n'êtes pas développeur, alors ça risque de ne pas vous servir en plus. Donc si vous voulez encore quitter la salle à ce moment-là, je ne vous en voudrais pas. Vous n'êtes même pas sur la vidéo. Du coup, on va commencer par se présenter. Oups. Bonjour, ben Loïc Martin. J'ai découvert WordPress il y a cette année. Je suis développeur de formation. Et Sylvain m'a demandé de l'aider pour l'atelier après qu'on aura. Donc je passerai peut-être dans les rames pour les aider. Je travaille aussi au support pour SécuPres pour ceux qui connaissent et je crée des sites à côté. Et bon, Sylvain chez l'enmerger. Donc j'ai commencé à développer et j'ai rencontré WordPress il y a trois ans. J'ai rencontré sa communauté qui m'a accueillie. Je suis également animateur dans une association lyonnaise qui s'appelle Les Bricodeurs. On fait de l'initiation à la programmation pour les adultes en reconversion et pour les enfants. Et à côté de ça, j'ai aussi, j'avais repris une formation de développement il y a un an que j'ai terminé pour apprendre un peu à faire de la qualité sur les développements que je fais et j'ai rejoint l'équipe Polylang pour l'occasion, donc l'équipe qui est dite l'expansion Polylang. C'est dans cet environnement qu'on a mis en place des tests automatisés. Et c'est de ça dont j'avais envie de vous parler aujourd'hui. Malheureusement, malheureusement je ne verrai pas le temps. En fait, il y a tout un tas de sujets super intéressants autour des tests automatisés. Je peux vous en parler pendant des heures si vous mal paguez dans les couloirs tout à l'heure, alors que je suis à peine débutant, mais on ne pourra pas parler des enjeux des tests automatisés, de comment évaluer la pertinence des tests automatisés qu'on met en place et de quelle stratégie adoptée pour mettre en place ces tests automatisés. C'est super intéressant, mais on n'en parlera pas. Il va falloir parler de quelque chose quand même. Qu'est-ce qu'on va faire ? On va commencer par faire une petite démystification de la terminologie. On va commencer par cette phrase. Les termes utilisés dans le milieu des tests automatisés, qu'est-ce que ça veut dire ? Le gros de la présentation, ce sera un atelier que vous pouvez suivre. D'ailleurs, à ce propos, j'ai une petite clé USB avec les fichiers dont vous allez avoir besoin si vous voulez suivre pas à pas la démonstration et on pourra éventuellement venir à la fin de la démonstration sur vos questions, sur vos soucis techniques et les réseaux américains, si tu peux la faire tourner à ceux qui ont aposté des ordinateurs. Et alors, si on a le temps, mais j'en doute, je vous parlerai un petit peu de qu'est-ce qu'on peut faire une fois qu'on a mis en place des tests automatisés, sur quoi on peut se lancer, ça peut être intéressant. Une dernière petite avertissement avant qu'on commence à proprement parler cette présentation. Donc, l'atelier qu'on va faire, ça va être une mise en place manuelle d'une suite de tests automatisés. Ce n'est vraiment pas une bonne pratique à faire. Je ne vous conseille pas de faire ça dans votre environnement professionnel. Par contre, la bonne nouvelle, c'est qu'a priori, on peut le faire quelque soit votre environnement de développement, quelque soit votre système d'exploitation, encore que je ne l'ai pas testé sous Mac. Donc voilà, on le fait pour cette fois-ci. C'est juste pour que vous compreniez le principe. Éventuellement, si le sujet vous intéresse, j'ai moi-même été inspiré par d'autres conférences. Donc la conférence de Richard Oz à Paris en 2015 et une autre plus récente, mais en anglais, donc de Carla Exander du CP Massa Picca et Thorsten Fromen au World Camp Europe de 2018, donc qui est sous le format atelier, mais qui commence par une présentation assez bien explicative sur ce que sont les tests et comment les faire. Du coup, j'avais promis qu'on parlerait du jargon des tests. Donc qu'est-ce que c'est, les tests vous en faites sans doute déjà tout un tas de tests de vos développements et dès qu'elles je vais parler. J'ai envie de vous parler des tests automatisés qui sont souvent mélangés, qui sont souvent raccourcis en tant que test unitaire, alors que les tests unitaires ça désigne quelque chose, certains tests qui sont en rapport avec les tests automatisés, mais ce n'est pas aussi général que test automatisé. Donc ça c'est une petite confusion qui est fréquente parce que des termes, il y en a un paquet. On entend souvent parler de tests unitermes, aussi de tests fonctionnels, de tests d'intégration, de tests d'acceptation, tout un tas et on a éventuellement leur correspondant en anglais ce qui n'aide pas non plus à la discussion. Je vais essayer de vous faire une petite sélection de trois termes et ce à quoi ils peuvent se rapporter. Donc d'abord les tests unitaires, donc ça a un mot très très populaire, qui correspondent à tester en fait un composant de notre application, donc vraiment une petite partie en isolation du reste de l'application. C'est-à-dire quand on fait un test unitaire, probablement tout ce qu'on va tester c'est du code qu'on a écrit, donc ça va être juste un petit bout de code en PHP qu'on a écrit nous-mêmes. Donc si vous faites un test unitaire, en général vous avez besoin dans votre environnement de développement uniquement de PHP. A contrario, il y a les tests d'intégration aussi, c'est à ce moment-là que vous allez prendre deux composants, vous allez essayer de les mettre ensemble et de voir ce que ça produit et de comparer cette interaction de vos composants avec le résultat que vous attendez. Donc si par exemple vous avez écrit du code en PHP ou essayer de voir ce que ça fait quand vous le mettez en relation avec une base MySQL, ça va être un test d'intégration et si vous regardez comment votre code PHP est intégré dans votre presse, ça va être aussi un test d'intégration probablement. Et le troisième terme dont je vais vous parler aujourd'hui, c'est les tests N2N, on entend plus souvent parler dans sa version anglaise, qui correspond à tester votre application dans la globalité de ce qu'elle fait, c'est-à-dire dans un environnement qui simule la réalité mais avant évidemment de l'avoir mis en production. Donc en général, pour piloter ces tests, vous avez besoin d'un navigateur web et pour que ces tests puissent tourner, vous avez aussi besoin d'un serveur web. Donc ces tests, on ne pourra pas les voir pendant l'atelier aujourd'hui parce que je ne sais pas les faire en fait. Voilà, tout simplement. Donc cette petite classification, évidemment ce n'est pas du tout une classification rigoureuse, ce n'est pas celle qui est approuvée par le comité français des tests logiciels. Donc si jamais certaines personnes sont intéressées pour avoir une définition plus technique, plus mathématique, je vous ai mis un petit lien vers le glossaire du CFTL mais il n'y a pas les références cinématographiques, donc c'est quand même un peu dommage. Donc à partir de là, j'ai défini ce qu'on appelle l'échelle du test, c'est-à-dire quelle partie de l'application test. Par contre, ces tests-là ne sont pas forcément automatisés. Par exemple, un test unitaire manuel que vous avez tous dû faire, c'est d'ouvrir votre fichier de code. À un endroit donné, vous savez qu'il y a un bug à peu près dans cette partie-là. À un endroit, vous insérez une valeur en dur. Un peu plus loin, vous mettez un warden ou quelque chose qui vous permet de récupérer des informations de votre code et en fait, vous avez fait un test unitaire mais manuel. Et puis une fois que vous avez fait ça, vous devez nettoyer votre code avant de l'envoyer aux clients. Bref, ce n'est pas super pratique. Donc comment on peut faire pour tester automatiquement son application ? Donc si vous voulez suivre l'atelier, il y a ce lien qui va vous permettre d'avoir les slides sur votre ordinateur. Pour lire les exemples de code, ça peut être plus pratique, même si je pense qu'ils sont assez gros. Et si vous n'avez pas eu la clé USB, ou si vous voulez le faire chez vous, il y a aussi les fichiers de l'atelier qui sont disponibles sur un UI transfert. Je ne sais pas mon corps combien de temps ça va rester. Je vous laisse le temps de taper cet adresse-là si jamais il y en a qui sont intéressés. En attendant, est-ce que c'était clair ? Est-ce que je vous ai raconté ? Il y a une question sur la terminologie des tests ? Ou ça va, j'enchaîne. Ok, alors on y va. Donc pour tester notre application, on va se mettre dans le cas d'une extension pour WordPress. On va utiliser un outil qui s'appelle PHP Unit. PHP Unit, c'est ce qu'on appelle un framework de test. Donc c'est vraiment un outil. C'est-à-dire qu'à la limite, il n'y en aurait pas besoin. Sauf que bon, écrire tout ce qu'il faut pour faire tourner des tests automatiques à la main, c'est long. Et en plus, on a besoin des mêmes choses à chaque fois. Donc autant utiliser cet outil qui s'appelle PHP Unit. PHP Unit, ce n'est pas le seul qui est disponible pour tester du code PHP. Par contre, c'est celui qui est utilisé par les contributeurs de WordPress pour tester WordPress lui-même. C'est quand même un outil qui a déjà pas mal de modules qui sont adaptés. Des personnes ont fait des configurations qui sont adaptées pour le faire tourner dans le cadre de WordPress. Comment faire tourner WordPress qui garantit une compatibilité encore avec PHP 5.6 ? Ça va nous limiter dans la version de PHP Unit qu'on peut utiliser. Donc on peut aller au maximum à la 7.5. Sinon après, c'est plus compatible avec PHP 5.6 et vous ne pouvez pas faire tourner vos tests automatiques. Donc PHP Unit, on peut le télécharger sur son site web. Dans le dossier que je vous ai passé, il y a la petite archive PHP de PHP Unit. Donc une archive PHP, c'est un fichier PHP qui va être lu comme par l'interprèteur PHP de votre environnement de développement. C'est ça qu'on va utiliser aujourd'hui. Évidemment pour l'utiliser, on va devoir faire de la ligne de commande. Donc s'il y en a qui développent, qui sont sur Linux, ça va leur faire plaisir parce que la ligne de commande, ils doivent bien connaître. Si vous êtes sous Windows, alors les versions récentes de Windows proposent d'avoir un terminal Linux qui imite Linux qui peut être pratique. Et si vous n'avez pas une version de Windows qui vous donne accès à un terminal qui vous permet de lancer des lignes de commande d'unix comme si vous étiez sur un environnement Linux, il y a ce petit utilitaire qui s'appelle Siegwin que je vous ai passé dans le dossier que je vous ai fait tourner sur la clé USB qui vous permet d'accéder à un environnement donc à un terminal de ligne de commande qui est tout à fait comme suite d'une distribution Linux. Donc pour vous déplacer dedans vos dossiers à l'aide de cette ligne de commande il faut utiliser la commande qui s'appelle CD et lui donner un chemin dans lequel vous voulez vous déplacer. Par exemple ici, dans le premier exemple, c'est pas un bon exemple parce que j'ai utilisé un petit raccourci qui est la tilde qui m'envoie dans mon dossier personnel. Dans mon dossier personnel, j'ai un dossier développement et dans mon dossier développement j'ai un dossier qui s'appelle MyPlugin donc j'ai envie de me déplacer dans ce dossier, j'ai envie de l'ouvrir à l'aide de la ligne de commande donc j'ai tapé CD Développement MyPlugin. Si vous le faites à partir de Siegwin, il faut aller dans un dossier qui est placé à la racine de votre système de fichier la racine qui est symbolisée par le slash en entrée donc un dossier qui s'appelle en général SiegDrive à partir de ce dossier-là, vous avez accès à toutes vos partitions Windows qui ont les mêmes lettres que celles que vous avez sur votre explorateur de fichier donc la partition C, la partition D, la partition E. Ensuite on va, on dit je vais dans la racine, je vais dans le dossier SiegDrive, dans le dossier SiegDrive, je vais dans le dossier C. Dans le dossier C j'ai un dossier développement, ça c'est chez moi, c'est de votre côté vous organisez comme vous voulez et dans ce dossier développement, j'ai un dossier MyPlugin et dans ce dossier MyPlugin je vais faire mes tests PHP Units. Est-ce que vous avez des questions à ce niveau-là ? Non ok, on a des bons geeks, ça fait plaisir. Donc oui j'avais dit qu'à l'avenir il faudra plus que vous utilisez cette méthode pour installer PHP Units. Il y a des méthodes beaucoup plus simples et beaucoup plus sûres qui existent comme d'utiliser un compositeur par exemple, un compositeur qui va vous permettre d'intégrer une version de PHP Units qui correspond à la version de PHP que vous êtes en train d'utiliser, donc ça peut être pas mal. En fait là j'ai dû spécifier moi-même le numéro de version que je voulais. Donc si vous avez l'habitude d'utiliser compositeur vous pouvez faire ça et après si vous faites vraiment des plugins WordPress le plus simple c'est encore d'utiliser la commande de WPCLI qui fait ça puisqu'elle va en plus de vous installer PHP Units elle va vous installer tout un environnement qui fait que votre PHP Units pourra aller lire dans WordPress pour faire des tests d'intégration avec WordPress et on va voir si j'ai le temps de vous les montrer. Donc ok, on a dit qu'on avait fait une extension pour WordPress on va faire un petit scénario. On va dire que c'est l'agence d'espion Pickertong qui veut faire un site WordPress pour ses agents secrets donc forcément il faut que ce site soit en langage codé parce que des agents secrets s'échangent les informations contre eux donc ils vont vouloir coder les messages qu'il y a sur le site WordPress. Alors comment on va s'y prendre ? On va faire une petite structure assez simple de dossier pour notre extension donc ça correspond sur la clé USB que je vous ai passée donc ça correspond à la première étape du développement d'extension celle qui s'appelle Pickertong Init donc il y a une structure de dossier assez simple en fait dans le dossier de mon extension j'ai un dossier source le dossier source il contient le code donc le code que je vais donner aux clients en gros le code qui va produire mon code de production qu'on appelle il y a un dossier test dans ce dossier là je vais écrire uniquement mes tests automatisés c'est à dire que tout ce que je vais écrire c'est pour moi c'est pour m'aider, c'est pour aller faire tourner mes tests pour voir si mon extension se comporte comme je l'attends je le mets dans ce dossier là le client n'a pas à avoir accès à ce dossier en général on ne lui passe que la source et dans le dossier 12 donc c'est là où j'ai mis PHP Unit ça aussi c'est juste pour moi de mon côté je vais faire tourner PHP Unit sur ma machine de développement une petite note pour ceux qui veulent faire ça de leur côté éventuellement il va falloir rendre PHP Unit exécutable parce que c'est une archive PHP c'est pas un format de fichier qui est forcément reconnu de base par votre système donc soit vous avez la petite commande Linux pour le faire en dessous soit vous pouvez le faire avec votre explorateur de fiers donc vous faites un clic droit sur le fichier et vous cherchez rendre exécutable, permission ou exécuté en tant que ça dépend des systèmes d'exploitation ok donc comment s'il prend, qu'est-ce que fait notre extension ça va être dans mon code source, mon code de production celui que je vais envoyer ensuite sur le répertoire des extensions WordPress pour que tout le monde puisse faire son site d'agent secret donc on a une fonction qui va en fonction d'un message qu'on lui fournit et d'un dictionnaire qui contient des nombres de codes et leurs significations associées cette fonction va être capable de traduire le message du langage codé en langage décodé donc en fait de la fonction vous n'avez pas spécialement besoin de savoir ce qu'elle fait à l'intérieur s'il y en a qui connaissent la fonction de PHP qui s'appelle Pregreplace ils auront compris vite ce que ça fait donc il faut juste savoir qu'en entrée j'ai un message codé et le dictionnaire avec les codes et leurs significations et en sortie j'ai le message décodé donc je vais vouloir écrire mon test dans mon fichier de test je vais utiliser une classe parce que c'est la manière dont fonctionne PHP Unit c'est en utilisant la syntaxe orientée objet de WordPress donc c'est à dire qu'on va écrire des classes PHP qui héritent de la classe test case de PHP Unit donc cette classe test case elle permet en fait d'avoir accès à toutes les fonctionnalités de PHP Unit donc on est obligé de faire comme ça et ensuite chacun de nos tests sera écrit dans une fonction à l'intérieur de cette classe dans une méthode du coup à l'intérieur de cette classe donc par exemple là mon premier test donc je vous montre la structure en général un test on le structure en trois étapes donc plus ou moins strict la première étape qui va être le contexte qu'on désigne souvent en anglais sous le nom de given c'est à dire selon une situation donnée imaginons que dans le cas de WordPress j'ai un certain article donc je vais créer manuellement cet article au début de mon test ensuite il y a la phase de action la phase qu'on appelle le when en anglais donc cette phase là ça veut dire que je vais exécuter la partie de mon application que je suis en train de tester si je suis en train de tester l'insertion d'articles dans la base de données je vais vérifier que cet article que j'ai écrit dans le contexte si je le passe dans l'action wp insert post il arrive dans la base de données et cette vérification je vais la faire à la troisième étape l'étape qu'on appelle le zen c'est à dire le zen thn rien à voir avec le zen z2n qui consiste à dire moi je me suis attendu à ce que mon article était enregistré dans la base de données est-ce que c'est bien le cas donc on va comparer à une situation qu'on attend au résultat de l'action précédente donc ça c'est les trois étapes assez classiques d'un test les structures peuvent varier mais ça tourne toujours à peu près autour de cette logique donc si je teste ma fonction qui décode des messages que je vous ai écris tout à l'heure par exemple vous avez on a le contexte donc on a un message qui nous dit le coucou a quitté son lit évidemment ce message est codé on a le dictionnaire qui contient les codes et leur signification donc on définit que le coucou ça se traduit par la cible dans notre jargon d'espion et que le lit ça se traduit par domicile dans notre jargon d'espion donc a priori si ma fonction de décodage de message je passe le message le coucou a quitté son lit que je lui passe ces noms de code là a priori donc le message que je vais obtenir donc le message décodé est équivalent à la cible a quitté son lit donc en fait pour vérifier cette égalité pour vérifier cette égalité je vais utiliser justement la fonction de PHP unit qui s'appelle assert equals donc voyez le petit zis c'est la raison pour laquelle on a utilisé une classe PHP unit qui nous donne accès à ce assert equals qui va nous dire je m'attends à ce que la phrase que j'ai décodé soit équivalente à la cible a quitté son lit ok donc là j'ai écrit mon test comment je le lance maintenant pour lancer le test je vais donc entrer en ligne de commande je vais me placer donc à la racine de mon de mon extension à la racine de mon fichier de développement et donc je vais eu dire je vais cibler cet archive PHP donc je vais lui donner le chemin jusqu'à l'archif PHP pour lui dire l'exécuter ensuite je vais lui je vais lui passer une option alors le petit antislash à la fin de la ligne ça c'est pour dire que toute cette commande ce sera une seule et même commande si vous voulez vous pouvez tout écrire sur la même ligne le petit antislash me permet de faire des sauts de ligne mais vous pouvez recopier ça ça va marcher aussi donc je donne le chemin vers mon archive PHP unit qui va me permettre de lancer ma suite de test en option je lui dis bootstrap ça veut dire au démarrage je veux que tu charges le fichier qui est dans le répertoire SRC le fichier d'écode.php qui contient le code de mon application je veux que tu le charge au démarrage de PHP unit et ensuite on va lui donner le nom du test donc de la classe de test que j'ai écrite donc je vais lui dire je veux que tu exécutes les tests qui sont dans la classe pnt des codes test et ensuite donc là il aurait fallu encore un petit antislash ici il est manquant et ensuite je vais lui dire cette classe de test tu la trouveras dans le fichier décode.php qui est cette fois dans le dossier dans le sous dossier test à partir de là PHP unit dans mon terminal il va me dire ohlala ça va pas du tout t'as fait une erreur il va me dire que j'ai fait une erreur de syntax en fait il me dit ok j'ai trouvé une erreur à tel endroit de ton code donc voilà il me dit hop à la ligne 7 de ton code ta fonction predreplace tu n'utilises pas bien du tout c'est pas comme ça qu'on fait ah bon d'accord ok donc on va essayer de le corriger ah oui en effet j'ai oublié un petit truc donc ceux qui connaissent la fonction predreplace auront compris ce qui la connaissent pas c'est pas vraiment le but de ma présentation donc je corrige juste pour que le paramètre que je passe à ma fonction soit conforme à ce qui est écrit dans la documentation PHP et à ce moment là je peux relancer mon code je peux relancer mes tests automatisés et mes tests automatisés qui me disent ok tu n'as plus une erreur de syntaxe maintenant tu as une erreur menthalogique ok donc elle va me dire ces deux chaînes ne sont pas égales en effet la cible a quitté son donc je m'attendais à avoir la cible a quitté son i et j'ai obtenu la cible a quitté son domicile et là on réfléchit ça un peu je me rappelle que ah oui en fait c'était la cible a quitté son domicile que je voulais obtenir donc je regarde le code de test le code du test je me dis oui en effet si dans la phrase le coucou a quitté son i je remplace le coucou par la cible et je remplace le ni par domicile oui normalement ça doit me donner la phrase la cible a quitté son domicile donc j'avais fait une erreur dans les tests donc ça peut arriver ça arrive souvent donc je vous conseille quand vous avez un test qui échoue déjà regardez si le test est correct est-ce que si votre test échoue mais que vous avez écrit n'importe quoi dans le test vous avancez sur la pertinence de votre application une fois qu'on a fait ça une fois qu'on a fait ça je peux relancer la même ligne de commande que je vous ai montré au début et là il va me dire ok ton test passe tout va bien, impeccable tu peux passer à la suite voilà ça fait plaisir à partir de là oui donc est-ce que ça a du sens pour tout le monde est-ce qu'il y a des questions déjà est-ce que vous voyez peut-être l'intérêt du truc est-ce qu'il y a une manière de le refaire une manière de faire qui peut vous poser problème si vous essayez de le faire chez vous non pas de questions particulières ok donc on a 2 possibilités soit on regarde un peu plus de fonctionnalité de PHP unit soit on part directement sur l'intégration des tests WordPress ou alors on peut essayer de voir pourquoi on peut vouloir implémenter des tests automatisés dans son développement qui est pour voir plus de fonctionnalité de PHP unit c'est pas fou qui est pour voir comment intégrer WordPress dans ces tests automatisés ok un peu plus qui aimerait bien savoir ce qu'on peut faire de rigolo avec des tests automatisés ah ah c'est assez prochain de l'autre pardon oui on voit tout ça va être compliqué alors WordPress allez on passe à WordPress alors pour intégrer vos tests dans WordPress rappelez-vous que je suis en train de faire une installation manuelle que je ne vous conseille pas donc en fait il va falloir que vous incluiez manuellement la version de développement de WordPress que vous trouvez sur un répertoire GitHub donc il s'appelle WordPress WordPress Develop donc celle-là je voulais passer dans la clé USB qui a tourné donc vous avez un WordPress Develop Master si je me souviens bien donc il contient la version de développement pour pouvoir inclure des tests automatisés donc c'est pas la méthode que je vous conseille de faire par la suite la méthode que je vous conseillerai de suivre par la suite c'est la méthode WP Cli donc vous trouverez la documentation au lien que je vous ai inclus en attendant si vous voulez le faire pour vous entraîner vous pouvez manuellement copier votre répertoire WordPress et WordPress Develop et le mettre dans l'extension dans l'architecture dossier de l'extension mais avant ça il va falloir qu'on configure un petit fichier sur un PHP unit et vous voulez pas que je vous en parle plus mais bon trop petit pour vous du coup dans la racine de notre extension on va inclure un petit fichier de configuration qui s'appelle PHP unit.xml PHP unit est configuré pour le détecter automatiquement quand vous le lancez la suite de test donc dans ce petit fichier on va écrire donc on va lui dire PHP unit j'ai des suites de test et dans cette suite de test j'en ai une qui s'appelle test PHP parce qu'aujourd'hui on fait des tests en PHP uniquement donc on va lui dire dans cette suite de test on va lui dire un répertoire un répertoire qui s'appelle test dans lequel tu vas chercher tous les tests que je vais lancer et ces tests commenceront obligatoirement par le prefix test et finiront par le suffix.php donc ça veut dire que là quand je vais lancer PHP unit il va regarder dans mon dossier test donc ici il va chercher tous les fichiers qui commencent par test et qui finissent par PHP il va dire ok là dedans il va avoir des tests, je lis les tests je les exécute du coup oui et ensuite il faut encore faire l'installation de WordPress donc on va copier WordPress développe dans un dossier quelque part on va mettre notre extension dans le sous-dossier des extensions de WordPress ensuite il faut lancer un serveur MySQL en intégration on va avoir besoin d'aller jusqu'à la base de données donc on va avoir besoin de serveurs MySQL qui tournent vous en avez intégré dans les warmth l'ample, l'exemple, tous les environnements de développement que vous pouvez avoir il faut créer une base de données nouvelle, vide sans rien que vous nommez comme vous voulez et ensuite dans le fichier dans le répertoire de WVP develop là vous faites là vous vous copiez le fichier qui s'appelle WVP test config simple et vous remplacez des constantes comme vous avez l'habitude pour intégrer la base de données que vous venez créer à WVP donc que vous venez de créer attention toutefois donc cette base de données faut absolument pas l'utiliser absolument pas la même que celle de votre de votre application que vous allez livrer parce que cette base de données elle va être effacée à chaque fois que vous allez lancer les tests automatisés donc il faut bien prendre une base de données distincte et une fois que vous avez donc vous avez modifié les constantes en rapport avec la base de données vous pouvez renommer votre fichier WVP test config simple et l'appeler juste WVP test config.php parce que c'est ça que le fichier de WordPress va lancer le ça qu'on va lancer pour au moment où WordPress est en mode test automatisé donc ces tests automatisés en fait ils vont être lancés par un fichier de démarrage donc là que j'ai copié que j'ai copié du script qui est exécuté par WVP c'est pas un fichier qu'on peut facilement inventer donc ce fichier c'est celui qui va lancer tout l'environnement WordPress dans un contexte de test automatisé en fait qui est fondamentalement différent d'un contexte d'utilisation de WordPress puisque en fait quand on utilise WordPress on est soit sur la partie front-office donc on est en face de notre site avec le thème le machin etc soit dans la partie back-office jamais les deux donc WordPress ne lance pas tous ces fichiers pour faire des tests automatisés on teste l'intégralité de l'application donc il faut que WordPress se lance dans un certain mode donc ils nous ont fourni un fichier qui permet de configurer ça ce fichier je l'ai placé dans mon sous-dossier de test et en fait je l'ai renseigné dans ma configuration PHP unit je l'ai renseigné dans le sous-dossier sa situation en fait en tant dans un attribut de la balise PHP unit donc pour lui dire quand tu lances PHP unit tu ouvres le fichier bootstrap.php tu l'exécutes tout son code et on continue donc ça c'est je vous disais ça ne s'invente pas ce qui est dans le fichier bootstrap donc il est fourni par WPSali vous le retapez pas à la main vous inquiétez pas la première ligne vous avez le répertoire dans lequel vous avez installé votre dossier WordPress développement donc il faut changer le chemin à partir de ce moment-là que vous l'avez changé en haut du fichier dans le reste du fichier il va utiliser ce chemin pour bien lancer WordPress au démarrage de PHP unit et éventuellement vous allez aussi avoir à changer cette ligne vous voyez que votre plugin il va devoir être chargé en même temps que WordPress pour ça il va falloir que vous donnez le nom du fichier de démarrage de votre plugin manuellement normalement il y a une ligne qui va être sample.php ou je ne sais plus donc vous modifiez cette ligne pour que au démarrage WordPress en mode test automatisé votre plugin soit également démarré oui et après ça va se faire tout seul donc oui donc ça c'est le petit fichier qui va instantier toute mon extension et bon bah c'est un fichier d'extension WordPress vous savez comment les écrire probablement je quand même mis le code au cas où donc à partir de là qu'est-ce qui se passe quand je lance ma commande PHP unit vous voyez que l'avantage du fichier de configuration c'est que par rapport à toutes les options que j'avais dures enseignées dans la première fois que j'ai lancé la commande maintenant je dis juste ok PHP unit lance-toi il cherche est-ce que j'ai un fichier PHP unit.xml oui j'ai un fichier PHP unit.xml il lit ce fichier de configuration et puis il dit ok donc je sais ce que je dois démarrer WordPress je sais que je vais donc voilà vous voyez que là il me dit ok on passe en mode WordPress single site voilà on se connecte à la base de nez etc. et puis là bah mes tests ils passent toujours puisque j'ai pas changé mon code de test et puis ma suite WordPress a été correctement instantiée donc il n'a pas de raison de s'arrêter il me dit ok tout est bon vous voyez aussi un petit truc qui a changé à 3 secondes 60 donc la durée d'exécution de tous les tests automatisés alors qu'avant on était plutôt sur 60 millisecondes ça c'est à partir du moment où vous commencez à intégrer des tests d'intégration avec des bases de nez forcément ça prend un peu plus de temps à faire tourner enfin faire des tests en 3 secondes 60 je pense que en mode manuel il y en a peu qui arrivent à les faire quand même et on va écrire le premier test d'intégration en fait il va tester si au moment où si j'arrive à lire un message codé qui aurait été écrit dans un titre dans des articles de WordPress donc comment je vais écrire ce test je vais utiliser une fonction très pratique qui m'a été fournie par j'ai oublié quelque chose j'ai oublié quelque chose je vous montrerai je verrai si j'ai la bonne diapo qui me permet de vous le montrer mais en gros WordPress nous ajoute des fonctions utilitaires dans sa suite de tests automatisés comme par exemple la possibilité de créer un poste facilement donc je ne vous détaille pas la syntaxe thisFactoryPostCreateRais ça vous insère un poste dans la base de données de WordPress donc là on voit que j'insère un poste avec le son titre qui est vôle au dessus d'un lit de coucou donc là mon poste est inséré c'est ma situation c'est mon contexte, c'est ma situation initiale ensuite je lui dis imaginons que je me rende donc ça c'est encore une fonction qui nous est fournie par la suite de tests automatisés de WordPress imaginons que je me rende sur la page avec l'identifiant de pages de l'article que je viens de créer donc en fait le poste a dit que j'ai récupéré juste au dessus donc cette fonction me crée un poste me retourne son identifiant dans la base de données je la fournis à ma fonction ok tu vas faire comme si il y avait quelqu'un qui se rendait sur la page de cet article et ensuite je vérifie en utilisant donc là pour le coup c'est une fonction de WordPress que vous connaissez probablement si vous avez programmé des thèmes donc The Title donc je récupère le title et je vérifie que mon title ça donne un vôle au dessus d'un domicile de cible puisqu'on remplace coucou par coutou par cible et ni par domicile donc pour ce faire là j'utilise une autre fonction de PHP Unit en fait vu que The Title c'est pas une fonction qui est censé me me renvoyer qui est pas censé me renvoyer une chaîne d'ailleurs c'était un peu bête de l'écrire ici ouais j'ai un peu écrit j'ai un peu mal écrit mais en fait tout ça pour vous dire que comme The Title ça va afficher une chaîne directement sur votre écran donc ça passe par le tampon de sortie de PHP donc je peux pas lui dire il faut que je trouve un moyen pour récupérer ce tampon de sortie PHP Unit l'a fait pour nous donc c'est en utilisant la méthode this expect output string donc il va dire ok la prochaine la prochaine prochaine donnée qui sont envoyées dans le tampon de sortie tu me les récupères et tu me les compares avec cette phrase que je t'ai donnée donc vole au dessus d'un domicile de signe donc tout ça il n'y a pas vraiment de documentation ou alors j'ai pas bien trouvé pour tout ce qui est test test unitaire comment utiliser l'environnement qui a déjà été écrit par les contributeurs de WordPress pour faire des tests automatisés donc il faut fouiller à la main dans le depot GitHub donc des fois c'est un peu compliqué mais on se débrouille et donc quand je vais lancer mon test à ah bah mon test il échoue ok donc vole au dessus d'un domicile de signe non c'est pas cette phrase que j'obtiens c'est vole au dessus de de 8000 de 8217 ni de coucou ok alors là ce qui est très intéressant c'est en fait j'ai fait un échec dans mon intégration dans mon intégration avec WordPress mais vous voyez que là-haut il y a 3 tests qui sont passés donc mes 2 tests précédents que j'avais écrits sont passés et mes tests unitaires m'ont dit ok ta fonction elle est correcte et mon test d'intégration me dit oui mais par contre quand tu essaies de lire un titre de WordPress il est pas du tout décodé et c'est là où ça devient intéressant c'est-à-dire que je sais que j'ai une fonction correcte mais elle est pas du tout elle est pas du tout bien intégrée dans WordPress et donc du coup la fonctionnalité je sais pas mais je sais où aller chercher je sais que c'est dans mon intégration avec WordPress qu'il y a un défaut et je pense que vous avez déjà quelques petites idées pour pouvoir le résoudre ça tombe bien parce que c'est là où je vais m'arrêter et si certaines personnes ont envie d'essayer de résoudre ce bug alors je vous préviens il y a quelque chose d'assez insupportable avec l'encodage de caractère mais si quand même vous voulez tenter il y a tout le le dépôt de cette présentation qui est en ligne sur GitHub vous avez vraiment la démarche pas à pas si vous savez un peu utiliser Git pour revenir en arrière dans les comites vous pouvez re-suivre cette démarche là si vous savez utiliser GitHub même ça peut le faire directement de l'interface web vous pouvez voir toutes les étapes et essayer d'aller plus loin si vous voulez proposer proposer d'efforts ou quoi moi je suis ouvert à ces propositions bon voilà c'est où je voulais amener ma démonstration ça s'est fait en 45 minutes presque donc partir de ce moment là est-ce qu'il y a des questions est-ce qu'il y a des gens qui ont essayé de le faire en même temps ou ça va fonctionner avec Composer top c'est le plus simple quand tu installes que PHP oui alors après faut que tu saches installer WordPress par Composer ça donc honnêtement je ne peux pas te guider dessus c'est pour ça que si tu veux faire du développement WordPress avec des tests automatisés je conseille de WPCali pour l'installation c'est le plus tout en voilà maintenant je suis ouvert aux questions des insertions sur les bases de données ou je sais comment alors je ne vais pas trouver de bonne façon de le faire en général tu utilises une fonction qui va chercher dans la base de données et tu compares cette donnée récupérée avec la donnée que tu t'attendais à ce qui soit enregistrée donc éventuellement éventuellement déjà si tu as recherche dans la base de données et te retourne une erreur déjà tu sais qu'il y a un problème à ce niveau-là et si ta donnée n'est pas la bonne l'avantage c'est que la base de données elle est réinitialisée à chaque lancement de la suite de tests donc a priori c'est pas tes tests d'avant qui ont fait foirer la base de données c'est vraiment qu'il y a un souci au moment où tu enregistres ta donnée