Uma das coisas que tenho feito um esfor\u00e7o muito mais concentrado, provavelmente mais do que j\u00e1 fiz antes, \u00e9 gerenciar a separa\u00e7\u00e3o de preocupa\u00e7\u00f5es entre as classes respons\u00e1veis \u200b\u200bpela interface com o WordPress e as respons\u00e1veis \u200b\u200bpor trabalhar com o dom\u00ednio do problema.<\/p>\n
Por exemplo, digamos que voc\u00ea esteja trabalhando em um plug-in e ele se comunicar\u00e1 com uma API de terceiros. Al\u00e9m disso, este plugin tamb\u00e9m oferecer\u00e1 menus, tipos de postagem, taxonomias e assim por diante na \u00e1rea de administra\u00e7\u00e3o do WordPress.<\/p>\n
H\u00e1 duas \u00e1reas de responsabilidade aqui:<\/p>\n
Voc\u00ea pode argumentar que \u00e9 importante testar as \u00e1reas de unidade que se comunicam com o WordPress, mas tamb\u00e9m sei que essas s\u00e3o APIs testadas e verdadeiras que t\u00eam seu pr\u00f3prio conjunto de testes.<\/p>\n
Em vez disso, devemos nos concentrar no teste de unidade e separar nossa l\u00f3gica de neg\u00f3cios do WordPress.<\/p>\n
Mas n\u00e3o \u00e9 esse o objetivo deste post. Em vez disso, trata-se mais de uma maneira de potencialmente apresentar um projeto quando uma parte dele far\u00e1 interface com o WordPress.<\/p>\n
J\u00e1 falei sobre a import\u00e2ncia e as vantagens dos namespaces em posts anteriores para n\u00e3o me aprofundar muito nessa discuss\u00e3o aqui.<\/p>\n
Em vez disso, estou interessado em falar sobre a organiza\u00e7\u00e3o de arquivos no n\u00edvel do sistema de arquivos e no n\u00edvel do namespace, para que sejam claramente separados em suas \u00e1reas de especializa\u00e7\u00e3o e para que possamos ter certeza de que estamos, digamos, focando nossos testes de unidade (e outros testes) em \u00e1reas que s\u00e3o mais cr\u00edticas.<\/p>\n
Eu gosto de ter certeza de que meu diret\u00f3rio e estrutura de arquivos espelham os meus namespaces. Claro, ajuda na organiza\u00e7\u00e3o dos arquivos, mas tamb\u00e9m na organiza\u00e7\u00e3o conceitual.<\/p>\n
Ou seja, se eu for trabalhar com meta boxes, ent\u00e3o eu sei que provavelmente posso encontrar os arquivos de meta box em um diret\u00f3rio aninhado com o diret\u00f3rio pai do WordPress<\/strong> e dentro de um subdiret\u00f3rio Admin<\/strong> seguido por um diret\u00f3rio MetaBox<\/strong>.<\/p>\n Para esse fim, como seria um conjunto de classes projetadas para trabalhar com meta caixas, dever\u00edamos escrever c\u00f3digo para elas de maneira reutiliz\u00e1vel? Dado o que sabemos sobre meta boxes, sabemos que provavelmente precisaremos do seguinte:<\/p>\n Dados os pontos acima, talvez a estrutura de diret\u00f3rios ficaria assim:<\/p>\n<\/p>\n Em seguida, temos o c\u00f3digo que espelha essa estrutura. Ou seja, dentro do nosso diret\u00f3rio WordPress<\/strong>, ter\u00edamos o subdiret\u00f3rio Admin<\/strong> j\u00e1 que a meta box \u00e9 exibida dentro da \u00e1rea de administra\u00e7\u00e3o do WordPress, e ter\u00edamos o subdiret\u00f3rio View<\/strong> que conteria o arquivo respons\u00e1vel por exibir as informa\u00e7\u00f5es.<\/p>\n Isso nos deixa com a necessidade de criar algumas classes, conforme listado acima. Talvez a classe base abstrata ficaria assim:<\/a><\/strong><\/p>\n Em seguida, uma implementa\u00e7\u00e3o concreta estenderia a classe e ficaria assim:<\/a><\/strong><\/p>\n E, finalmente, a visualiza\u00e7\u00e3o da classe conteria qualquer c\u00f3digo de marca\u00e7\u00e3o e modelo para renderiza\u00e7\u00e3o de informa\u00e7\u00f5es<\/a><\/strong> :<\/p>\n Isso nos d\u00e1 exatamente o que precisamos de uma maneira bem organizada e reutiliz\u00e1vel para trabalhar com meta caixas. Tamb\u00e9m pode ser repetido para itens como menus, tipos de postagem, taxonomias e assim por diante.<\/p>\n Mas eu discordo.<\/p>\n Como mencionei anteriormente no post, acredito que as classes de teste de unidade que resolvem problemas exclusivos do nosso espa\u00e7o de problemas s\u00e3o importantes. Isso significa que voc\u00ea precisa dizer ao seu arquivo de configura\u00e7\u00e3o PHPUnit para excluir seus arquivos centrados no WordPress.<\/p>\n A vantagem do que expus acima \u00e9 que isso se torna trivialmente f\u00e1cil. Simplificando, voc\u00ea pode adicionar isso<\/a><\/strong> ao seu arquivo phpunit.xml<\/strong> :<\/p>\n Isso lhe d\u00e1 a capacidade de se concentrar em escrever testes especificamente para o seu espa\u00e7o de problema, ao mesmo tempo em que garante que voc\u00ea est\u00e1 escrevendo c\u00f3digo baseado em WordPress escal\u00e1vel, sustent\u00e1vel e reutiliz\u00e1vel.<\/p>\n Atualmente estou escrevendo um eBook (junto com uma variedade de outros conte\u00fados premium). Se voc\u00ea estiver interessado, confira o que voc\u00ea recebe<\/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>\nUma palavra sobre teste de unidade (com 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