L’une des choses sur lesquelles j’ai fait un effort beaucoup plus concert\u00e9, probablement plus que jamais auparavant, est la gestion de la s\u00e9paration des pr\u00e9occupations entre les classes responsables de l’interface avec WordPress et celles charg\u00e9es de travailler avec le domaine probl\u00e9matique.<\/p>\n
Par exemple, disons que vous travaillez sur un plugin et qu’il va communiquer avec une API tierce. De plus, ce plugin proposera \u00e9galement des menus, des types de publication, des taxonomies, etc. dans la zone d’administration de WordPress.<\/p>\n
Il y a deux domaines de responsabilit\u00e9 ici :<\/p>\n
Vous pouvez faire valoir qu’il est important de tester les zones qui communiquent avec WordPress, mais je sais aussi que ce sont des API \u00e9prouv\u00e9es qui ont leur propre ensemble de tests.<\/p>\n
Au lieu de cela, nous devrions nous concentrer sur les tests unitaires et s\u00e9parer notre logique m\u00e9tier de WordPress.<\/p>\n
Mais ce n’est pas le propos de ce post. Au lieu de cela, il s’agit plut\u00f4t d’un moyen de pr\u00e9senter potentiellement un projet lorsqu’une partie de celui-ci s’interfacera avec WordPress.<\/p>\n
J’ai parl\u00e9 de l’importance et des avantages des espaces de noms dans des articles pr\u00e9c\u00e9dents afin de ne pas plonger trop profond\u00e9ment dans cette discussion ici.<\/p>\n
Au lieu de cela, je suis int\u00e9ress\u00e9 \u00e0 parler de l’organisation des fichiers au niveau du syst\u00e8me de fichiers et au niveau de l’espace de noms, afin qu’ils soient clairement s\u00e9par\u00e9s dans leurs domaines de sp\u00e9cialisation et afin que nous puissions nous assurer que nous concentrons, disons, nos tests unitaires (et d’autres tests) sur les zones les plus critiques.<\/p>\n
J’aime m’assurer que la structure de mon r\u00e9pertoire et de mes fichiers refl\u00e8te celle de mes espaces de noms. Bien s\u00fbr, cela aide \u00e0 l’organisation des fichiers, mais aussi \u00e0 une organisation conceptuelle.<\/p>\n
Autrement dit, si je vais travailler avec des bo\u00eetes de m\u00e9ta, je sais que je peux probablement trouver les fichiers de bo\u00eete de m\u00e9ta dans un r\u00e9pertoire imbriqu\u00e9 avec le r\u00e9pertoire WordPress<\/strong> parent, puis dans un sous-r\u00e9pertoire Admin<\/strong> suivi d’un r\u00e9pertoire MetaBox<\/strong>.<\/p>\n \u00c0 cette fin, \u00e0 quoi pourrait ressembler un ensemble de classes con\u00e7ues pour travailler avec des m\u00e9ta-bo\u00eetes si nous \u00e9crivions du code pour elles de mani\u00e8re r\u00e9utilisable\u00a0? Compte tenu de ce que nous savons des m\u00e9ta-bo\u00eetes, nous savons que nous aurons probablement besoin des \u00e9l\u00e9ments suivants\u00a0:<\/p>\n Compte tenu des points ci-dessus, peut-\u00eatre que la structure du r\u00e9pertoire ressemblerait \u00e0 ceci\u00a0:<\/p>\n<\/p>\n Ensuite, nous avons un code qui refl\u00e8te cette structure. Autrement dit, dans notre r\u00e9pertoire WordPress<\/strong>, nous aurions le sous-r\u00e9pertoire Admin<\/strong> puisque la bo\u00eete m\u00e9ta est affich\u00e9e dans la zone d’administration de WordPress, et nous aurions le sous-r\u00e9pertoire View<\/strong> qui contiendrait le fichier responsable de l’affichage des informations.<\/p>\n Cela nous oblige \u00e0 cr\u00e9er quelques classes comme indiqu\u00e9 ci-dessus. Peut-\u00eatre que la classe de base abstraite ressemblerait \u00e0 ceci\u00a0:<\/a><\/strong><\/p>\n Ensuite, une impl\u00e9mentation concr\u00e8te \u00e9tendrait la classe et ressemblerait \u00e0 ceci\u00a0:<\/a><\/strong><\/p>\n Et enfin, la vue de la classe contiendrait tout code de balisage et de mod\u00e8le pour le rendu des informations<\/a><\/strong>\u00a0:<\/p>\n Cela nous donne exactement ce dont nous avons besoin d’une mani\u00e8re bien organis\u00e9e et r\u00e9utilisable pour travailler avec les m\u00e9ta-bo\u00eetes. Il peut \u00e9galement \u00eatre r\u00e9p\u00e9t\u00e9 pour des \u00e9l\u00e9ments tels que les menus, les types de publication, les taxonomies, etc.<\/p>\n Mais je m’\u00e9gare.<\/p>\n Comme je l’ai mentionn\u00e9 plus t\u00f4t dans l’article, je pense que les classes de tests unitaires qui r\u00e9solvent des probl\u00e8mes propres \u00e0 notre espace de probl\u00e8mes sont importantes. Cela signifie que vous devez indiquer \u00e0 votre fichier de configuration PHPUnit d’exclure vos fichiers centr\u00e9s sur WordPress.<\/p>\n L’avantage de ce que j’ai expos\u00e9 ci-dessus est que cela devient trivialement facile. En termes simples, vous pouvez ajouter ceci<\/a><\/strong> \u00e0 votre fichier phpunit.xml<\/strong>\u00a0:<\/p>\n Cela vous donne la possibilit\u00e9 de vous concentrer sur l’\u00e9criture de tests sp\u00e9cifiquement pour votre espace de probl\u00e8mes tout en vous assurant que vous \u00e9crivez un code bas\u00e9 sur WordPress \u00e9volutif, maintenable et r\u00e9utilisable.<\/p>\n J’\u00e9cris actuellement un livre \u00e9lectronique (avec une vari\u00e9t\u00e9 d’autres contenus premium). Si vous \u00eates int\u00e9ress\u00e9, regardez ce que vous obtenez<\/a>.<\/p>\n\n
<?php\n\nnamespace AcmeWordPressAdminMetaBox;\n\nabstract class AbstractMetaBox\n{\n protected $postType;\n\n public function __construct()\n {\n $this->postType = 'acme_post_type';\n }\n\n abstract public function render();\n abstract public function display();\n}\n<\/code><\/pre>\n<?php\n\nnamespace AcmeWordPressAdminMetaBox;\n\nclass AcmeMetaBox extends AbstractMetaBox\n{\n \/**\n * {@inheritdoc}\n *\/\n public function render()\n {\n add_meta_box(\n 'acme-product-image',\n 'Product Image',\n [$this, 'display'],\n $this->postType,\n 'side',\n 'default'\n );\n }\n\n \/**\n * {@inheritdoc}\n *\/\n public function display()\n {\n include_once plugin_dir_path(__FILE__).'Views\/acme-product-image.php';\n }\n}\n<\/code><\/pre>\n<div class=\"product-image-metabox\">\n <p>\n <img src=\"<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>\" alt=\"<?= esc_attr(get_the_title()); ?>\" \/>\n <input type=\"text\" value=\"<?= esc_html(get_post_meta(get_the_ID(), 'product_image', true)); ?>\" \/>\n <\/p>\n<\/div><\/code><\/pre>\nUn mot sur les tests unitaires (avec PHPUnit)<\/h3>\n
<testsuites>\n <testsuite name=\"Plugin\">\n <directory>.\/tests<\/directory>\n <exclude>.\/tests\/phpunit<\/exclude>\n <exclude>.\/src\/WordPress<\/exclude>\n <\/testsuite>\n<\/testsuites><\/code><\/pre>\n