Share
Dans les deux derniers articles, nous avons examiné de près la théorie derrière les tests unitaires et comment cela peut nous aider dans nos efforts de développement WordPress. Nous avons défini les tests unitaires et examiné diverses manières dont ils peuvent nous aider tout au long de nos projets..
Mais nous avons encore plus à couvrir.
Dans cet article final, nous verrons pourquoi nous devrions même nous préoccuper de faire des tests unitaires et nous résumerons les avantages et les inconvénients de le faire. Ensuite, nous verrons comment intégrer les tests dans nos projets existants. Et pour terminer, nous allons résumer une liste de ressources qui sont spécifiquement disponibles pour nous, développeurs WordPress, qui aideront à commencer à tester nos thèmes à l'unité..
Le thème principal de toute cette série a été la raison pour laquelle nous devrions nous préoccuper des tests unitaires, mais si cela n’a pas été précisé de manière succincte, voici pourquoi:
Les tests unitaires nous aident à détecter rapidement les problèmes, à fournir aux développeurs un niveau de code auto-documenté et à améliorer la qualité des logiciels..
Certes, cela suppose que nous appliquions de bonnes techniques de tests unitaires. Bien sûr, cela a été couvert en détail dans l'article précédent, mais il convient de répéter.
Il est important de noter - en particulier si vous essayez d'appliquer cela dans un contexte plus corporatif ou dans le contexte d'une entreprise plus grande - que les tests unitaires ne sont pas simplement quelque chose que les développeurs font pour eux-mêmes. La qualité est bilatérale: elle profite au client et à l'entreprise..
En fournissant un niveau de qualité supérieur au client, c'est-à-dire un logiciel testé de manière plus approfondie, le nombre de bogues rencontrés devrait être réduit. Etant donné que les bogues entraînent un temps que les développeurs doivent consacrer à la résolution plutôt que de travailler sur de nouveaux projets ou de nouvelles fonctionnalités de produits existants, cela peut finalement permettre de réaliser des économies..
En offrant un niveau de qualité supérieur à l'entreprise, les développeurs ont davantage confiance en leurs efforts, car ils peuvent exécuter une série de tests chaque fois qu'un changement est apporté, en sachant que leur travail a affecté l'ensemble de l'application. Si un test échoue, ils peuvent le résoudre avant de le déployer en production..
Le test unitaire concerne la qualité et n'affecte pas seulement ceux qui écrivent le code, mais aussi l'entreprise qui l'exporte, ainsi que les clients qui l'utilisent..
La vérité est que nous avons déjà exposé les avantages des tests unitaires. Pour être complet, résumons-les ici (même si vous pouvez toujours les revoir en détail!). Tests unitaires…
Tout sonne bien, non? Et oui, il est fondé sur le principe que les développeurs doivent se conformer à des normes et à des pratiques strictes en ce qui concerne leur mise en œuvre quotidienne, mais les tests unitaires ne sont pas sans inconvénients..
Cela a été dit tout au long de cette série: les tests unitaires prennent un investissement de temps considérable. Certes, si vous démarrez un nouveau projet, l’investissement en temps est beaucoup moins important que si vous intégrez cela dans une application existante, mais encore avoir à écrire plus de code que sans test.
Comme vous écrivez plus de code, vous prenez plus de temps - encore une fois, au début du projet. Les avantages des tests unitaires ne viennent souvent que tardivement, mais si un projet a une date cible spécifique pour la publication et que cette version inclut un certain nombre de fonctionnalités, vous ne pourrez probablement pas intégrer tous les tests unitaires et les fonctionnalités dans La version.
Si vous souhaitez éviter des ensembles de fonctionnalités plus petits aux dates de lancement ou aux dates cibles retardées, vous devez avoir gagner du temps pour les tests unitaires.
Vous les avez tous entendus: la complexité tue, restez simple, stupide, moins c'est plus, etc..
Honnêtement, toutes ces affirmations sont vraies et ont leur place dans le développement, mais le fait est que les tests unitaires est code supplémentaire et code supplémentaire toujours introduit plus de complexité. En tant que tel, nous devons nous assurer de disposer d’un moyen approprié pour gérer et organiser tous nos tests unitaires..
Il s’agit peut-être de l’organisation de fichiers, de l’espacement des noms, des conventions de dénomination, des tests versionnés ou de tout ce qui précède. Quoi que vous fassiez, les tests unitaires ne doivent pas être traités comme des citoyens de seconde classe dans le monde des logiciels - ils doivent autant que possible être soumis aux mêmes principes de conception que les autres classes ou fonctions..
Oui, dans le dernier article, nous avons expliqué que les tests unitaires peuvent aider à orienter la conception d'une application et à favoriser une conception qui rende l'application plus testable. C'est toujours vrai, mais cela coûte cher: parfois, la conception la plus testable par unité n'est pas la plus claire..
J'entends par là que, parce qu'un ensemble de fonctions - ou même une classe - est entièrement testé en unité, la cohésion peut être compromise, car nous faisons des sacrifices pour accéder à certaines fonctions afin de vérifier leur traitement des données. Bien sûr, ce n’est pas une règle absolue et ce n’est peut-être pas un problème pour certains, mais vous devez décider en quoi vous allez devenir dogmatique: s'agit-il d'un ensemble de classes et / ou de fonctions parfaitement conçu? un système contigu de tests et de fonctions qui fonctionnent ensemble?
En fin de compte, je pense que cela dépend de la façon dont vous considérez les tests comme une plus grande partie de l’ensemble. S'ils font partie de la conception de votre application, celle-ci peut ne pas en souffrir. Mais si vous considérez les tests après coup, la conception de l’application principale risque d’être légèrement compromise..
Comme on dit, les logiciels ne sont jamais finis et puisque les tests unitaires font partie d’un logiciel, ce n’est jamais fait..
Parce qu'une application va toujours évoluer, que ce soit des bugs supprimés, de nouvelles fonctionnalités introduites (ou même supprimées), les tests associés devront également être ajoutés ou mis à jour. Et ça revient toujours dans le temps.
De plus, si vous travaillez dans une équipe de développeurs, notre manque de tests de mise à jour peut avoir un impact négatif sur l'équipe car les résultats rapportés par les tests peuvent être des faux positifs ou des faux négatifs. Une fois les tests écrits, il est impératif de les mettre à jour. sinon, ils peuvent donner un très mauvais produit.
Le test unitaire est une vente beaucoup plus facile lorsque vous débutez avec un projet, mais si vous souhaitez l'adapter à une application existante (ou à un thème ou à un plugin, dans notre cas), cela prendra un peu de temps et effort.
Et bien qu'il n'y ait pas de solution miracle pour savoir comment vous pouvez parfaitement exécuter cela, il existe quelques bonnes façons de commencer à appliquer la pratique dans votre travail quotidien:
Si vous suivez les étapes ci-dessus, vous obtiendrez éventuellement une couverture importante du code. Oui, cela prend du temps et vous devrez probablement retravailler une bonne partie du code, mais cet investissement vous rapportera des dividendes dans le futur de votre produit..
Voici un résumé des ressources pouvant contribuer à la réussite des tests de vos projets WordPress:
Entre la première série d'articles et cette série d'articles, une base solide a été posée sur laquelle vous pouvez continuer à construire vos pratiques de tests unitaires..
Accentsconagua