En av de saker som jag har gjort en mycket mer samlad anstr\u00e4ngning, troligen mer \u00e4n jag n\u00e5gonsin har gjort tidigare, \u00e4r att hantera separationen av problem mellan klasserna som ansvarar f\u00f6r gr\u00e4nssnittet med WordPress och de som \u00e4r ansvariga f\u00f6r att arbeta med problemdom\u00e4nen.<\/p>\n
L\u00e5t oss till exempel s\u00e4ga att du arbetar med ett plugin och att det kommer att kommunicera med ett tredje parts API. Dessutom kommer detta plugin ocks\u00e5 att erbjuda menyer, inl\u00e4ggstyper, taxonomier och s\u00e5 vidare inom WordPress administrationsomr\u00e5det.<\/p>\n
H\u00e4r finns tv\u00e5 ansvarsomr\u00e5den:<\/p>\n
Du kan h\u00e4vda att det \u00e4r viktigt att enhetstesta omr\u00e5den som kommunicerar med WordPress, men jag vet ocks\u00e5 att dessa \u00e4r bepr\u00f6vade API:er som har sina egna tester.<\/p>\n
Ist\u00e4llet borde vi fokusera p\u00e5 enhetstestning och separera v\u00e5r aff\u00e4rslogik fr\u00e5n WordPress.<\/p>\n
Men det \u00e4r inte meningen med det h\u00e4r inl\u00e4gget. Ist\u00e4llet handlar det mer om ett s\u00e4tt att eventuellt l\u00e4gga upp ett projekt n\u00e4r en del av det kommer att ha gr\u00e4nssnitt med WordPress.<\/p>\n
Jag har pratat om vikten och f\u00f6rdelarna med namnutrymmen i tidigare inl\u00e4gg s\u00e5 att jag inte ska g\u00e5 f\u00f6r djupt in i den diskussionen h\u00e4r.<\/p>\n
Ist\u00e4llet \u00e4r jag intresserad av att prata om att organisera filer p\u00e5 filsystemniv\u00e5 och namnomr\u00e5desniv\u00e5, s\u00e5 att de \u00e4r renodlade i sina specialiseringsomr\u00e5den och s\u00e5 att vi kan se till att vi, s\u00e4g, fokuserar v\u00e5ra enhetstester (och andra testning) p\u00e5 omr\u00e5den som \u00e4r mest kritiska.<\/p>\n
Jag vill se till att min katalog och filstruktur speglar mina namnomr\u00e5den. Visst, det hj\u00e4lper med filorganisation, men ocks\u00e5 med en konceptuell organisation.<\/p>\n
Det vill s\u00e4ga, om jag ska arbeta med metaboxar, d\u00e5 vet jag att jag sannolikt kan hitta metaboxfilerna i en katalog kapslad med den \u00f6verordnade WordPress-<\/strong> katalogen och sedan i en Admin-<\/strong> underkatalog f\u00f6ljt av en MetaBox-<\/strong> katalog.<\/p>\n F\u00f6r det \u00e4ndam\u00e5let, hur kan en upps\u00e4ttning klasser som \u00e4r designade f\u00f6r att arbeta med metaboxar se ut om vi ska skriva kod f\u00f6r dem p\u00e5 ett \u00e5teranv\u00e4ndbart s\u00e4tt? Med tanke p\u00e5 vad vi vet om metaboxar vet vi att vi sannolikt kommer att beh\u00f6va f\u00f6ljande:<\/p>\n Med tanke p\u00e5 ovanst\u00e5ende punkter kanske katalogstrukturen skulle se ut s\u00e5 h\u00e4r:<\/p>\n<\/p>\n D\u00e4refter har vi kod som speglar denna struktur. Det vill s\u00e4ga, i v\u00e5r WordPress-<\/strong> katalog skulle vi ha underkatalogen Admin<\/strong> eftersom metarutan visas inom administrationsomr\u00e5det f\u00f6r WordPress, och vi skulle ha underkatalogen Visa<\/strong> som skulle inneh\u00e5lla filen som \u00e4r ansvarig f\u00f6r att visa informationen.<\/p>\n Detta g\u00f6r att vi beh\u00f6ver skapa n\u00e5gra klasser enligt listan ovan. Kanske skulle den abstrakta basklassen se ut s\u00e5 h\u00e4r:<\/a><\/strong><\/p>\n Sedan skulle en konkret implementering ut\u00f6ka klassen, och den skulle se ut s\u00e5 h\u00e4r:<\/a><\/strong><\/p>\n Och slutligen skulle vyn f\u00f6r klassen inneh\u00e5lla valfri uppm\u00e4rkning och mallkod f\u00f6r att rendera information<\/a><\/strong> :<\/p>\n Detta ger oss precis vad vi beh\u00f6ver p\u00e5 ett v\u00e4lorganiserat, \u00e5teranv\u00e4ndbart s\u00e4tt f\u00f6r att arbeta med metaboxar. Det kan ocks\u00e5 upprepas f\u00f6r saker som menyer, inl\u00e4ggstyper, taxonomier och s\u00e5 vidare.<\/p>\n Men jag avviker.<\/p>\n Som jag n\u00e4mnde tidigare i inl\u00e4gget tror jag att enhetstestningsklasser som l\u00f6ser problem som \u00e4r unika f\u00f6r v\u00e5rt problemutrymme \u00e4r viktiga. Detta inneb\u00e4r att du m\u00e5ste tala om f\u00f6r din PHPUnit-konfigurationsfil att utesluta dina WordPress-centrerade filer.<\/p>\n F\u00f6rdelen med det jag har lagt upp ovan \u00e4r att detta blir trivialt enkelt. Enkelt uttryckt kan du l\u00e4gga till detta<\/a><\/strong> till din phpunit.xml<\/strong> -fil:<\/p>\n Detta ger dig m\u00f6jligheten att fokusera p\u00e5 att skriva tester specifikt f\u00f6r ditt problemutrymme samtidigt som du ser till att du skriver skalbar, underh\u00e5llbar och \u00e5teranv\u00e4ndbar WordPress-baserad kod.<\/p>\n Jag h\u00e5ller f\u00f6r n\u00e4rvarande p\u00e5 att skriva en e-bok (tillsammans med en m\u00e4ngd annat premiuminneh\u00e5ll). Om du \u00e4r intresserad, kolla in vad du f\u00e5r<\/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>\nEtt ord om enhetstestning (med 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