\u00dcks asi, mida olen teinud palju koosk\u00f5lastatumalt, t\u00f5en\u00e4oliselt rohkem kui kunagi varem, on murede eraldamine WordPressiga liidestamise ja probleemse domeeniga t\u00f6\u00f6tamise eest vastutavate klasside vahel.<\/p>\n
Oletame n\u00e4iteks, et t\u00f6\u00f6tate pistikprogrammi kallal ja see hakkab suhtlema kolmanda osapoole API-ga. Lisaks pakub see pistikprogramm WordPressi haldusalas ka men\u00fc\u00fcsid, postituste t\u00fc\u00fcpe, taksonoomiat ja nii edasi.<\/p>\n
Siin on kaks vastutusvaldkonda:<\/p>\n
V\u00f5ite v\u00e4ita, et WordPressiga suhtlevate testpiirkondade \u00fchendamine on oluline, kuid ma tean ka, et need on proovitud ja t\u00f5elised API-d, millel on oma testide komplekt.<\/p>\n
Selle asemel peaksime keskenduma \u00fcksuste testimisele ja eraldama oma \u00e4riloogika WordPressist eemale.<\/p>\n
Aga see pole selle postituse m\u00f5te. Selle asemel on tegemist pigem viisiga, kuidas projekti potentsiaalselt paika panna, kui osa sellest liidestub WordPressiga.<\/p>\n
Olen varasemates postitustes r\u00e4\u00e4kinud nimeruumide t\u00e4htsusest ja eelistest, et ma sellesse arutelusse siin liiga s\u00fcgavalt ei sukelduks.<\/p>\n
Selle asemel tahaksin r\u00e4\u00e4kida failide korraldamisest failis\u00fcsteemi ja nimeruumi tasemel, et need oleksid selgelt oma spetsialiseerumisvaldkondadeks eraldatud ja et saaksime olla kindlad, et keskendume n\u00e4iteks oma \u00fcksusetestidele (ja muudele testimine) piirkondades, mis on k\u00f5ige kriitilisemad.<\/p>\n
Mulle meeldib veenduda, et mu kataloog ja failistruktuur peegeldavad minu nimeruumide struktuuri. Muidugi, see aitab failide korraldamisel, aga ka kontseptuaalsel korraldusel.<\/p>\n
See t\u00e4hendab, et kui ma hakkan t\u00f6\u00f6tama metakastidega, siis tean, et leian t\u00f5en\u00e4oliselt metakastifailid kataloogist, mis on pesastatud WordPressi<\/strong> emakataloogiga, seej\u00e4rel administraatori<\/strong> alamkataloogist, millele j\u00e4rgneb MetaBoxi<\/strong> kataloog.<\/p>\n Kuidas v\u00f5iks sel eesm\u00e4rgil v\u00e4lja n\u00e4ha metakastidega t\u00f6\u00f6tamiseks m\u00f5eldud klasside komplekt, kui peaksime neile korduvkasutatavat koodi kirjutama? Arvestades seda, mida me metakastide kohta teame, teame, et vajame t\u00f5en\u00e4oliselt j\u00e4rgmist.<\/p>\n Arvestades \u00fclaltoodud punkte, v\u00f5ib kataloogi struktuur v\u00e4lja n\u00e4ha selline:<\/p>\n<\/p>\n J\u00e4rgmisena on meil kood, mis peegeldab seda struktuuri. See t\u00e4hendab, et meie WordPressi<\/strong> kataloogis oleks meil alamkataloog Admin<\/strong>, kuna metakast kuvatakse WordPressi haldusalas, ja meil oleks alamkataloog Vaade<\/strong>, mis sisaldaks teabe kuvamise eest vastutavat faili.<\/p>\n See j\u00e4tab meile vajaduse luua m\u00f5ned \u00fclaltoodud klassid. V\u00f5ib-olla n\u00e4eks abstraktne baasklass v\u00e4lja selline:<\/a><\/strong><\/p>\n Siis laiendaks konkreetne teostus klassi ja see n\u00e4eks v\u00e4lja j\u00e4rgmine:<\/a><\/strong><\/p>\n Ja l\u00f5puks, klassi vaade sisaldaks mis tahes m\u00e4rgistus- ja mallikoodi teabe renderdamiseks<\/a><\/strong> :<\/p>\n See annab meile t\u00e4pselt selle, mida vajame h\u00e4sti organiseeritud korduvkasutataval viisil, et t\u00f6\u00f6tada metakastidega. Seda saab korrata ka selliste asjade puhul nagu men\u00fc\u00fcd, postituste t\u00fc\u00fcbid, taksonoomiad jne.<\/p>\n Aga ma kaldun k\u00f5rvale.<\/p>\n Nagu ma varem postituses mainisin, usun, et meie probleemiruumile ainulaadseid probleeme lahendavad \u00fchikutestimise tunnid on olulised. See t\u00e4hendab, et peate oma PHPUniti konfiguratsioonifailile \u00fctlema, et WordPressi-kesksed failid v\u00e4listaks.<\/p>\n Selle eeliseks, mida ma eespool kirjeldasin, on see, et see muutub triviaalselt lihtsaks. Lihtsamalt \u00f6eldes saate selle lisada<\/a><\/strong> oma faili phpunit.xml<\/strong> :<\/p>\n See annab teile v\u00f5imaluse keskenduda spetsiaalselt oma probleemiruumi jaoks m\u00f5eldud testide kirjutamisele, tagades samal ajal, et kirjutate skaleeritavat, hooldatavat ja taaskasutatavat WordPressi-p\u00f5hist koodi.<\/p>\n Kirjutan praegu e-raamatut (koos mitme muu esmaklassilise sisuga). Kui olete huvitatud, vaadake, mida saate<\/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>\nM\u00f5ni s\u00f5na \u00fcksuste testimise kohta (koos PHPUnitiga)<\/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