Share
En fonction de vos antécédents, vous avez peut-être entendu parler de test unitaire, de développement piloté par le test, de développement piloté par le comportement ou d'un autre type de méthodologie de test. Souvent, ces méthodologies sont appliquées dans le contexte de systèmes logiciels ou d’applications plus vastes et moins dans le contexte de projets basés sur WordPress (bien qu’il est aller mieux!)
Franchement, la communauté de développement est un peu divisée en tests de logiciels automatisés - certaines personnes pensent que vous devriez avoir des tests pour 100% de votre code, certaines pensent que 80% sont suffisantes, d’autres environ 50% et d’autres se contentent de. 20% ou plus. Quoi qu'il en soit, cet article ne traite pas de l'argumentation quant au niveau de tests que vous devriez avoir dans votre projet, ni ne prend position sur les tests logiciels en général..
Au lieu de cela, nous allons examiner ce qui est nécessaire pour être opérationnel avec le test unitaire de vos projets de développement WordPress. Nous allons aborder cette série du point de vue du débutant absolu afin de pouvoir comprendre les avantages des tests unitaires et la façon de configurer notre environnement pour prendre en charge les bibliothèques de tests unitaires afin que nous puissions commencer à le faire dans nos travaux futurs. Finalement, tout cela sera fait en construisant et en testant un plugin simple et testable à partir de zéro.
Avant de commencer à configurer notre environnement et à écrire n’importe quel code, définissons exactement ce que sont les tests unitaires, pourquoi ils valent la peine d’être réalisés et comment commencer à les intégrer à nos projets..
À haut niveau, le test unitaire fait référence à la pratique consistant à tester certaines fonctions et zones - ou unités - de notre code. Cela nous donne la possibilité de vérifier que nos fonctions fonctionnent comme prévu. C'est-à-dire que pour toute fonction et à partir d'un ensemble d'entrées, nous pouvons déterminer si la fonction renvoie les valeurs appropriées et gérera avec élégance les échecs au cours de l'exécution si une entrée invalide est fournie..
En fin de compte, cela nous aide à identifier les défaillances de nos algorithmes et / ou de notre logique afin d’améliorer la qualité du code qui compose une certaine fonction. Au fur et à mesure que vous écrivez de plus en plus de tests, vous créez une suite de tests que vous pouvez exécuter à tout moment du développement pour vérifier en permanence la qualité de votre travail..
Un deuxième avantage à aborder le développement du point de vue des tests unitaires est que vous allez probablement écrire un code facile à tester. Étant donné que les tests unitaires exigent que votre code soit facilement testable, cela signifie que votre code doit prendre en charge ce type d'évaluation. En tant que tel, il est plus probable que vous disposiez d'un plus grand nombre de fonctions plus petites et plus ciblées qui fournissent une seule opération sur un ensemble de données plutôt que de grandes fonctions exécutant plusieurs opérations différentes..
Un troisième avantage pour écrire des tests unitaires solides et du code bien testé est que vous pouvez empêcher toute modification ultérieure de la fonctionnalité. Puisque vous testez votre code lorsque vous introduisez votre fonctionnalité, vous allez commencer à développer une suite de scénarios de test pouvant être exécutée chaque fois que vous travaillez sur votre logique. Quand un échec se produit, vous savez que vous avez quelque chose à résoudre.
Bien sûr, cela se fait au détriment de l'investissement de temps pour écrire une série de tests au début du développement, mais à mesure que le projet se développe, vous pouvez simplement exécuter les tests que vous avez développés pour vous assurer que les fonctionnalités existantes ne sont pas endommagées lorsque de nouvelles fonctionnalités sont disponibles. introduit.
L'un des meilleurs moyens de démarrer avec les tests unitaires consiste à le faire dans le contexte d'une application pratique. Tout au long de cette série en deux parties, nous allons créer un plugin simple et écrire des tests pour couvrir toutes les fonctionnalités..
Tout d’abord, planifions le projet: nous allons écrire un petit plugin qui ajoutera un simple message en haut d’un message qui accueille l’utilisateur en fonction de la façon dont il a trouvé un article de blog spécifique. L'idée est très similaire à celle de Welcome Reader, mais elle n'inclut pas autant de fonctionnalités. Nous construisons simplement une démonstration pour apprendre les tenants et les aboutissants des tests..
Quoi qu'il en soit, voici comment le plugin fonctionnera:
Assez simple, non? Cela fournira également une base sur laquelle ajouter des messages personnalisés pour d'autres services et étendre davantage nos capacités de test unitaire si vous le souhaitez..
Afin de tester un peu notre code, nous aurons besoin d'une bibliothèque tierce que nous inclurons dans notre projet et qui exécutera les tests que nous écrivons. Dans cette série, nous allons utiliser PHPUnit. Vous pouvez en prendre un exemplaire ici.
Ensuite, nous devons préparer notre environnement de développement, décomposer notre plugin et inclure les bibliothèques nécessaires pour tester notre code. Cet article suppose que vous disposez déjà d’une installation fonctionnelle de WordPress.
Alors, commençons par préparer le répertoire du plugin:
Voici le squelette du plugin que nous allons créer:
/ * Nom du plug-in: Bonjour Reader: URI du plug-in: http://github.com/tommcfarlin/Hello-Reader Description: Un plug-in simple utilisé pour illustrer les tests unitaires dans le contexte de WordPress. Version: 1.0 Auteur: Tom McFarlin Auteur URI: http://tom.mcfarl.in Email de l'auteur: [email protected] Licence: Copyright 2012 Tom McFarlin ([email protected]) Ce programme est un logiciel libre; vous pouvez le redistribuer et / ou le modifier selon les termes de la licence publique générale GNU, version 2, telle que publiée par la Free Software Foundation. Ce programme est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE; sans même la garantie implicite de QUALITÉ MARCHANDE ou d'ADÉQUATION À UN USAGE PARTICULIER. Voir la licence publique générale GNU pour plus de détails. Vous devriez avoir reçu une copie de la licence publique générale GNU avec ce programme; sinon, écrivez à la Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA * / // Créez uniquement une instance du plug-in si elle n'existe pas déjà dans GLOBALS si (! array_key_exists ('hello-reader', $ GLOBALS)) classe Hello_Reader function __construct () // constructeur de fin // fin de classe // Stocke une référence au plugin dans GLOBALS afin que nos tests unitaires puissent y accéder GLOBALS ['hello-reader'] = new Hello_Reader (); // fin si
À ce stade, vous devriez pouvoir accéder aux "plug-ins" de votre tableau de bord WordPress et voir une entrée pour "Hello Reader". De toute évidence, ce plugin ne fait rien pour l'instant - nous allons nous concentrer sur cela (ainsi que sur la raison pour laquelle nous exploitons la $ GLOBALS tableau) dans le prochain article.
Enfin, configurons le framework de test pour pouvoir écrire nos tests. Premièrement, nous devrons installer PHPUnit, puis les tests WordPress..
Remarque: La section suivante nécessitera des travaux avec le terminal et nécessitera probablement que vous utilisiez quelques commandes pour créer des liens symboliques. J'ai essayé de rendre cette tâche aussi simple et directe que possible, mais chaque système d'exploitation et chaque configuration seront différents. S'il vous plaît suivez attentivement et je vous invite à partager vos instructions pour vos systèmes d'exploitation dans les commentaires.
PHPUnit est un package de framework de test unitaire spécialement conçu pour PHP. Les tests WordPress et le cadre que nous allons utiliser pour écrire nos tests WordPress en dépendent. Malheureusement, l'installation varie en fonction de votre plate-forme. J'utilise actuellement Mac OS X Lion avec MAMP Pro et PHP 5.3.6. Si vous utilisez une autre plate-forme, assurez-vous de consulter la documentation et / ou n'hésitez pas à partager vos étapes dans les commentaires..
Commencez par ouvrir un terminal et mettre à jour pear (il s’agit de la facilité que nous utiliserons pour installer PHPUnit):
$ cd /Applications/MAMP/bin/php/php5.3.6/bin$ sudo ./pear upgrade pear
Ensuite, demandez à Pear d’utiliser les référentiels que nous spécifierons dans le terminal:
$ sudo /Applications/MAMP/bin/php/php5.3.6/bin/pear config-set auto_discover 1
Ensuite, installez Pear en lançant la commande suivante:
$ sudo /Applications/MAMP/bin/php/php5.3.6/bin/pear installer pear.phpunit.de/PHPUnit
Cela installera PHPUnit dans le contexte de votre installation MAMP. Pour le tester, exécutez la commande suivante dans votre session de terminal:
$ / Applications / MAMP/bin/php/php5.3.6/bin/phpunit --version
Après quoi le message suivant devrait être affiché:
PHPUnit 3.6.11 par Sebastian Bergmann.
Remarque: Si vous obtenez une erreur de terminal qui mentionne "unserialize ()", il existe un écart entre la configuration de pear et votre version de pear. Pour résoudre ce problème, lancez la commande suivante (elle renomme simplement le fichier si vous souhaitez le restaurer ultérieurement):
$ /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf.old
Maintenant que PHPUnit est installé et fonctionnel, il est temps de configurer WordPress Testing Framework. Vous pouvez récupérer le paquet de GitHub. Si vous êtes à l'aise pour cloner le référentiel, n'hésitez pas à le faire. sinon, il suffit de télécharger une archive du projet et de l'extraire dans le tester répertoire que nous avons créé plus tôt dans cet article.
Avant d'exécuter les tests, nous devrons créer un fichier de configuration pour exécuter les tests WordPress. C’est exactement comme éditer le wp-config.php fichier avec une nouvelle installation WordPress, mais nous le faisons pour une base de données de test. Ci-dessous, j'ai collé mon fichier de configuration et ajouté des commentaires. Je serai sûr de commettre ceci dans le dépôt GitHub de cet article, aussi.
Accentsconagua
/ * Chemin vers la base de code WordPress par rapport à l’emplacement de ces tests. Comme ils sont inclus dans notre plugin, nous nous référons à quelques répertoires ci-dessus. * / define ('ABSPATH', '… /… /… /… /… /'); / * Nom de la base de données pour l'exécution des tests. Assurez-vous qu'il s'agit d'une base de données destinée uniquement aux tests, car elle est créée et supprimée lors des tests. * / define ('DB_NAME', 'jetable'); / * Les informations d'identification habituelles pour une base de données locale. * / define ('DB_USER', 'root'); define ('DB_PASSWORD', "); define ('DB_HOST', 'localhost'); define ('DB_CHARSET', 'utf8'); define ('DB_COLLATE',"); define ('WPLANG', "); define ('WP_DEBUG', true); define ('WP_DEBUG_DISPLAY', true); define ('WP_TESTS_DOMAIN', 'localhost'); define ('WP_TESTS_EMAIL','[email protected] '); define (' WP_TESTS_TITLE ',' Blog test '); / * Ne vous inquiétez pas pour le test des réseaux ou des sous-domaines, définissez donc sur false. * / define (' WP_TESTS_NETWORK_TITLE ',' Test Network '); define (' WP_TESTS_SUBDOMAIN_INSTALL ',' false); $ base = '/'; / * Cron tente d'envoyer une requête HTTP au blog, qui échoue toujours, car les tests sont exécutés en mode CLI uniquement * / define ('DISABLE_WP_CRON', true); / * Pas également intéressé par le test de multisite pour ce projet, définissez donc sur false. * / define ('WP_ALLOW_MULTISITE', false); if (WP_ALLOW_MULTISITE) define ('WP_TESTS_BLOGS', 'premier, deuxième, troisième, quatrième'); if (WP_ALLOW_MULTISITE) &&! define ('WP_INSTALLING')) define ('SUBDOMAIN_INSTALL', WP_TESTS_SUBDOMAIN_INSTALL); define ('MULTISITE', true); define ('DOMAIN_CURRENT_SITE', WP_TESTS_DOMAIN '; WP_TESTS_DOMAIN') efine ('SITE_ID_CURRENT_SITE', 1); define ('BLOG_ID_CURRENT_SITE', 1); $ table_prefix = 'wp_'; Pour vérifier que vous avez correctement installé les tests, vous pouvez exécuter la commande suivante dans votre terminal:
$ / Applications / MAMP/bin/php/php5.3.6/bin/phpunit all
Si vous obtenez une erreur, c'est parce que les tests WordPress tentent d'utiliser un socket vers la base de données MySQL plutôt que celui utilisé par MAMP. Pour résoudre ce problème, nous devons créer un lien symbolique depuis le socket de MAMP vers l'emplacement sur le disque utilisé par les tests unitaires. Émettez les commandes suivantes dans votre session de terminal:
$ sudo mkdir / var / mysql $ sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock $ sudo ln -s / Applications/MAMP/tmp/mysql/mysql/mysql.sm $ var / mysql / mysql.sock
Maintenant, essayez de relancer les tests et vous devriez voir quelque chose comme la capture d'écran suivante.
Encore une fois, votre kilométrage peut varier en fonction de la plateforme que vous utilisez, alors n'hésitez pas à partager votre expérience dans les commentaires ou même à vous engager dans le fichier README sur GitHub afin que d'autres puissent avoir un point de référence..
À ce stade, nous sommes prêts à commencer à créer notre plug-in et à écrire nos tests unitaires. Le code ci-dessus a été ajouté à GitHub et je le construirai au fur et à mesure que nous travaillons dans le prochain article de la série. En attendant, assurez-vous de bien configurer votre environnement et d’être prêt à commencer le développement. Dans le prochain article, nous commencerons à écrire des tests, à construire notre plugin et à voir tout le projet se réaliser du début à la fin..
