{"id":230648,"date":"2022-11-27T14:21:00","date_gmt":"2022-11-27T11:21:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=230648"},"modified":"2022-11-27T14:23:06","modified_gmt":"2022-11-27T11:23:06","slug":"scrivere-unit-test-con-phpunit-parte-2-the-tear-down","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/it\/scrivere-unit-test-con-phpunit-parte-2-the-tear-down\/","title":{"rendered":"Scrivere Unit Test con PHPUnit, Parte 2: The Tear Down"},"content":{"rendered":"\n<p><strong><a href=\"https:\/\/wordpress.mediadoma.com\/it\/scrivere-unit-test-con-phpunit-parte-1-il-set-up\/\" title=\"Alla fine del mese scorso\">Alla fine del mese scorso<\/a><\/strong>, ho iniziato a parlare di scrivere unit test in PHPUnit per codice basato su WordPress. Ci\u00f2 includeva principalmente l&#8217;idea di impostare <strong><a href=\"https:\/\/phpunit.de\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">PHPUnit<\/a><\/strong>, la <strong>funzione setUp<\/strong> e la scrittura di test di base.<\/p>\n<p>Questo, tuttavia, non ha discusso di ci\u00f2 che so sulla funzione <strong>tearDown<\/strong>, che \u00e8 ancora una caratteristica importante della scrittura utilizzando i test. Inoltre, ci sono anche due modi per considerare la scrittura di test per i progetti WordPress.<\/p>\n<p>Vale a dire:<\/p>\n<ol>\n<li>scrivere test specifici per plug-in e funzionalit\u00e0 a livello di applicazione,<\/li>\n<li>eseguire unit test sull&#8217;applicazione WordPress.<\/li>\n<\/ol>\n<p>Prima di andare avanti con questo particolare post, per\u00f2, ti consiglio di recuperare ci\u00f2 che ho trattato finora. Ci\u00f2 include i seguenti post:<\/p>\n<ol>\n<li><strong><a href=\"https:\/\/wordpress.mediadoma.com\/it\/un-ambiente-di-sviluppo-wordpress-utilizzando-un-gestore-di-pacchetti\/\" title=\"Un ambiente di sviluppo WordPress (utilizzando un gestore di pacchetti)\">Un ambiente di sviluppo WordPress (utilizzando un gestore di pacchetti)<\/a><\/strong><\/li>\n<li><a href=\"https:\/\/wordpress.mediadoma.com\/it\/un-ide-per-lo-sviluppo-di-wordpress-indipendentemente-dallesperienza\/\" title=\"Un IDE per lo sviluppo di WordPress\">Un IDE per lo sviluppo di WordPress<\/a><\/li>\n<li><strong><a href=\"https:\/\/wordpress.mediadoma.com\/it\/utilizzo-delle-impostazioni-utente-in-visual-studio-code\/\" title=\"Utilizzo delle impostazioni utente in Visual Studio Code\">Utilizzo delle impostazioni utente in Visual Studio Code<\/a><\/strong><\/li>\n<li><a href=\"https:\/\/wordpress.mediadoma.com\/it\/scrivere-unit-test-con-phpunit-parte-1-il-set-up\/\" title=\"Scrivere Unit Test con PHPUnit, Parte 1: Il Set Up\">Scrivere Unit Test con PHPUnit, Parte 1: Il Set Up<\/a><\/li>\n<\/ol>\n<p>Dopo averlo fatto, torna a questo post e continuiamo a discutere della funzione tearDown e dell&#8217;aspetto effettivo degli unit test nel contesto di WordPress.<\/p>\n<h2>Unit test con PHPUnit, parte 2: The Tear Down<\/h2>\n<p>Prima di andare avanti, ricorda che gli sviluppatori spesso trattano la funzione <strong>setUp<\/strong> come il costruttore e la funzione <strong>tearDown<\/strong> come un distruttore; tuttavia, ricorda che quest&#8217;ultimo non \u00e8 sempre necessario.<\/p>\n<p>Ecco una buona regola pratica da ricordare:<\/p>\n<ul>\n<li>Tutto ci\u00f2 di cui una funzione di test ha bisogno chiamer\u00e0 la funzione <strong>setUp<\/strong> in modo che siano necessarie le classi necessarie.<\/li>\n<li>La funzione <strong>tearDown<\/strong> non \u00e8 sempre necessaria poich\u00e9 la funzione <strong>setUp<\/strong> pu\u00f2 reinizializzare una classe.<\/li>\n<\/ul>\n<p>Quindi cosa significa per la funzione <strong>tearDown<\/strong> se non sta ripristinando i dati creati durante la funzione di <strong>configurazione<\/strong>? <\/p>\n<h3>1 La funzione di smontaggio<\/h3>\n<p>Il miglior consiglio che posso dare sulla funzione <strong>tearDown<\/strong> \u00e8 che dovrebbe essere usata se qualcosa viene impostato durante uno dei test che viene lasciato indietro.<\/p>\n<p>Potrebbe trattarsi di qualcosa che viene scritto su un database, qualcosa che viene scritto su un registro o, pi\u00f9 in generale, qualcosa che viene scritto sul disco rigido.<\/p>\n<p>Pertanto, se un test scrive un record o un file, il metodo <strong>tearDown<\/strong> verr\u00e0 eseguito dopo un test e dovrebbe rimuovere qualsiasi test registrato sull&#8217;unit\u00e0 che non fa parte del test ma non \u00e8 permanentemente necessario per il test successivo o quello dovrebbe essere pulito dopo se stesso.<\/p>\n<p>Quindi, in un certo senso, \u00e8 come un <strong><a href=\"http:\/\/en.cppreference.com\/w\/cpp\/language\/destructor\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">distruttore<\/a><\/strong>, ma se non hai mai usato un linguaggio che ha un distruttore quella nomenclatura o sembra irrilevante o non ha senso.<\/p>\n<blockquote>\n<p>Un <strong>distruttore<\/strong> \u00e8 una funzione membro speciale che viene chiamata al termine della durata di un oggetto. Lo scopo del <strong>distruttore<\/strong> \u00e8 di liberare le risorse che l&#8217;oggetto potrebbe aver acquisito durante la sua vita.<\/p>\n<\/blockquote>\n<p>Quindi, forse \u00e8 meglio pensare semplicemente alla funzione come a un modo per ripulire dopo un test (e non nel senso di impostare una variabile uguale a null poich\u00e9 la funzione <strong>setUp<\/strong> pu\u00f2 farlo).<\/p>\n<h3>2 test unitari per progetti WordPress<\/h3>\n<p>Quando scriviamo unit test per progetti WordPress, dobbiamo assicurarci di essere chiari sul tipo di unit test di cui stiamo parlando.<\/p>\n<p>Ad esempio, quelli che chiamer\u00f2 unit test classici o standard seguono la metodologia dello &#8220;sviluppo test-driven&quot; di cui parler\u00f2 tra poco. D&#8217;altra parte, WordPress ha una propria serie di unit test per temi e simili di cui parler\u00f2 anche un po&#8217; pi\u00f9 avanti in questo post.<\/p>\n<p>Ma per questa sezione, ho pensato che potesse essere utile parlare un po&#8217; del primo piuttosto che del secondo in modo da poter vedere come potrebbe funzionare.<\/p>\n<p>Nell&#8217;esempio seguente, sto scrivendo test su un plug-in responsabile della comunicazione con un&#8217;API di terze parti. Questo particolare plugin richiede un nome utente e una password o un&#8217;API <strong>e<\/strong> vogliamo assicurarci che, ai fini di questo post, recuperi correttamente un errore ogni volta che viene eseguito il test.<\/p>\n<p>Nota che durante la lettura di questo codice, mi vedrai parlare un po&#8217; di riflessione. Presto scriver\u00f2 un intero post su PHP Reflection, quindi si far\u00e0 un po&#8217; di luce su questo.<\/p>\n<p>Per il codice seguente, tuttavia, supponiamo che sia un modo per poter accedere a propriet\u00e0 altrimenti contrassegnate come private.<\/p>\n<p>Ricordiamo dall&#8217;ultimo post di questa serie, abbiamo fatto un test iniziale <strong><a href=\"https:\/\/gist.github.com\/tommcfarlin\/248c7741273e6be414c1f98c11085fe7#file-01-acme-cache-test-php\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">simile a questo:<\/a><\/strong><\/p>\n<pre><code>&lt;?php\n\nuse PHPUnitFrameworkTestCase;\n\nclass AcmeCacheTest extends TestCase\n{\n  protected $cache;\n\n  protected function setUp()\n  {\n    $this-&gt;cache = new AcmeCache();\n  }\n\n  public function testDefaultDuration()\n  {\n    $this-&gt;assertTrue($this-&gt;cache-&gt;getDuration() === 43200);\n  }\n\n  public function testNewDuration()\n  {\n    $this-&gt;cache-&gt;setDuration(1000);\n\n    $this-&gt;assertFalse($this-&gt;cache-&gt;getDuration() === 43200);\n    $this-&gt;assertTrue($this-&gt;cache-&gt;getDuration() === 1000);\n  }\n\n  \/\/ More to come...\n}<\/code><\/pre>\n<p>Si noti, tuttavia, che in questo test non esiste una funzione <strong>di tearDown<\/strong> che abbia senso, giusto? Dopotutto, non viene scritto nulla su un database o su un file.<\/p>\n<p>Ma supponiamo di voler introdurre un test case che avr\u00e0 un nome file, un contenuto e scriver\u00e0 il contenuto nel file. In questo caso, saranno dati statici, ma tecnicamente potrebbe essere qualsiasi cosa scritta su disco.<\/p>\n<h4>1 Impostazione del test<\/h4>\n<p><strong><a href=\"https:\/\/gist.github.com\/tommcfarlin\/ca4f83191255e661a84e3563b27263de#file-00-initial-set-up-php\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">Innanzitutto<\/a><\/strong>, vogliamo impostare il test definendo il nome del file, il contenuto del file e preparando le propriet\u00e0.<\/p>\n<pre><code>&lt;?php\n\nnamespace PresswareAcmeTestsAPI;\n\nuse PHPUnitFrameworkTestCase;\n\nclass AcmeFileTest extends TestCase\n{\n\n  private $filename;\n\n  private $content;\n\n  public function setUp()\n  {\n    $this-&gt;filename = 'testFile.txt';\n    $this-&gt;content = 'This is a string of data that is meant to be written to the file.';\n  }\n\n  \/\/ More to come...\n}\n<\/code><\/pre>\n<p>Abbastanza facile, giusto?<\/p>\n<h4>2 Scrivere e leggere i dati<\/h4>\n<p>Successivamente, vogliamo scrivere i dati, leggere i dati e affermare che i contenuti <strong><a href=\"https:\/\/gist.github.com\/tommcfarlin\/ca4f83191255e661a84e3563b27263de#file-01-testing-contents-php\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">sono gli stessi.<\/a><\/strong><\/p>\n<pre><code>&lt;?php\n\nnamespace PresswareAcmeTestsAPI;\n\nuse PHPUnitFrameworkTestCase;\n\nclass AcmeFileTest extends TestCase\n{\n\n  private $filename;\n\n  private $content;\n\n  public function setUp()\n  {\n    $this-&gt;filename = 'testFile.txt';\n    $this-&gt;content = 'This is a string of data that is meant to be written to the file.';\n  }\n\n  public function testWriteReadData()\n  {    \n    \/\/ Writes the content to the file with the given filename.\n    $fileHandle = fopen($this-&gt;filename, 'w');\n    fwrite($fileHandle, $this-&gt;content);\n    fclose($fileHandle);\n\n    \/\/ Reads the contents of the file that was just written\n    $fileHandle = fopen($this-&gt;filename, 'r');\n    $contents = fread($fileHandle, filesize($this-&gt;filename));\n    fclose($fileHandle);\n\n    $this-&gt;assertSame($this-&gt;content, $contents);\n  }\n\n  \/\/ More to come..\n}\n<\/code><\/pre>\n<p>A questo punto, se esegui il test (che non ho ancora spiegato tecnicamente su come fare), noterai che <strong>testFile.txt<\/strong> risiede ancora sul tuo sistema.<\/p>\n<h4>3 Utilizzo dello smontaggio<\/h4>\n<p>Infine, dobbiamo lavorare con il metodo <strong>tearDown<\/strong> per assicurarci che il file venga eliminato al termine dello unit test. <strong><a href=\"https:\/\/gist.github.com\/tommcfarlin\/ca4f83191255e661a84e3563b27263de#file-02-full-test-php\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">Ecco come potrebbe apparire<\/a><\/strong> se hai implementato il tuo codice come quello che vedi sopra.<\/p>\n<pre><code>&lt;?php\n\nnamespace PresswareAcmeTestsAPI;\n\nuse PHPUnitFrameworkTestCase;\n\nclass AcmeFileTest extends TestCase\n{\n\n  private $filename;\n\n  private $content;\n\n  public function setUp()\n  {\n    $this-&gt;filename = 'testFile.txt';\n    $this-&gt;content = 'This is a string of data that is meant to be written to the file.';\n  }\n\n  public function testWriteReadData()\n  {    \n    \/\/ Writes the content to the file with the given filename.\n    $fileHandle = fopen($this-&gt;filename, 'w');\n    fwrite($fileHandle, $this-&gt;content);\n    fclose($fileHandle);\n\n    \/\/ Reads the contents of the file that was just written\n    $fileHandle = fopen($this-&gt;filename, 'r');\n    $contents = fread($fileHandle, filesize($this-&gt;filename));\n    fclose($fileHandle);\n\n    $this-&gt;assertSame($this-&gt;content, $contents);\n  }\n\n  public function tearDown()\n  {\n    if (file_exists($this-&gt;filename)) {\n      unlink($this-&gt;filename);\n    }\n  }\n}\n<\/code><\/pre>\n<p>Si noti che nel metodo <strong>tearDown<\/strong>, prima controllo per vedere se un <a href=\"https:\/\/php.net\/manual\/en\/function.file-exists.php\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">file_exists<\/a>. Questo perch\u00e9 se tenti semplicemente di <a href=\"https:\/\/php.net\/manual\/en\/function.unlink.php\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">scollegare<\/a> un file che non \u00e8 presente, riceverai un errore durante l&#8217;esecuzione dei test perch\u00e9 se \u00e8 presente <strong>tearDown<\/strong>, prover\u00e0 a eliminare qualcosa dopo ogni singola funzione di test. E se il file non esiste, non c&#8217;\u00e8 nulla da eliminare e quindi risulter\u00e0 un problema.<\/p>\n<p>Quindi, nel tentativo di scrivere codice in modo difensivo, credo che sia responsabile del controllo se il file esiste prima di provare effettivamente a eliminarlo.<\/p>\n<h3>3 Ordine delle operazioni<\/h3>\n<p>Quando si tratta di puro unit test, normalmente lo si legge in termini di <strong><a href=\"https:\/\/en.wikipedia.org\/wiki\/Test-driven_development\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">sviluppo basato su test<\/a><\/strong>. Questo \u00e8 un grande argomento in s\u00e9 e per s\u00e9; tuttavia, vale la pena menzionarlo qui se dovessi scegliere di ricercarlo ulteriormente e persino implementarlo nei tuoi sforzi di sviluppo.<\/p>\n<p>L&#8217;idea generale alla base di questo approccio viene spesso definita &quot;ripetizione rosso-verde&quot;. E non lo nego, c&#8217;\u00e8 qualcosa in questo approccio. Vale a dire, ti consente, come sviluppatore, di scrivere il codice come ti aspetti che funzioni prima di scrivere effettivamente il codice.<\/p>\n<p>La psicologia dietro \u00e8 questa: se sai come funziona il codice, \u00e8 pi\u00f9 probabile che tu scriva test che passano; mentre, se scrivi test su come dovrebbe funzionare il codice, dovresti scrivere un codice migliore.<\/p>\n<p>Sfortunatamente, non sempre ci viene concesso quel lusso. Ma questo non significa che dovremmo buttare fuori il proverbiale bambino con l&#8217;acqua. Invece, sono della mentalit\u00e0 che dovresti scrivere test quando puoi e scrivere il codice in seguito; in caso contrario, scrivi i tuoi test dopo il tuo codice.<\/p>\n<p>In definitiva, avere i test in atto a prescindere sar\u00e0 meglio che nessun test.<\/p>\n<h3>4 Test con WordPress<\/h3>\n<p>Quando si tratta di unit test in WordPress, ci sono alcune cose in cui probabilmente ti sei imbattuto. A volte, il contenuto \u00e8 un termine improprio o pu\u00f2 persino essere fuorviante in termini di &quot;test unitario in WordPress&quot;.<\/p>\n<p><a href=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-164139-61e75e67162bf.png\" data-rel=\"lightbox\"><img decoding=\"async\" class=\"SDStudio-light-box-enable SDStudio-editor-tools-md-imp\" src=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-164139-61e75e67162bf.png\" alt=\"Scrivere Unit Test con PHPUnit, Parte 2: The Tear Down\"><\/a><\/p>\n<p>Ad esempio, ci sono due cose degne di nota:<\/p>\n<ol>\n<li><strong><a href=\"https:\/\/codex.wordpress.org\/Theme_Unit_Test\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">Il test dell&#8217;unit\u00e0 tematica<\/a><\/strong>. Questo particolare insieme di contenuti ha lo scopo di aiutare gli sviluppatori di temi a testare tutti i casi principali e minori per i loro temi. Non ci sono strumenti automatizzati, ad esempio, che useresti come in quello che abbiamo discusso sopra.<\/li>\n<li><strong><a href=\"https:\/\/make.wordpress.org\/core\/handbook\/testing\/automated-testing\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">Test automatizzati<\/a><\/strong>. WordPress viene fornito con il proprio set di unit test in modo da non dover scrivere test sulla maggior parte delle funzionalit\u00e0 di WordPress (ad esempio se le funzioni API funzionano o meno come previsto). Questo ci permette di concentrarci sulla scrittura di unit test per la nostra logica di dominio.<\/li>\n<li><strong><a href=\"https:\/\/make.wordpress.org\/cli\/handbook\/plugin-unit-tests\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">Test unit\u00e0 plug-in<\/a><\/strong>. Se hai utilizzato WP-CLI (o ti interessa), probabilmente hai letto questa pagina o addirittura utilizzato questi strumenti. \u00c8 utile, ma mira anche ad aspetti specifici del test dei plugin di WordPress.<\/li>\n<\/ol>\n<p>Tutto quanto sopra \u00e8 un&#8217;informazione utile e non sto dicendo che dovrebbe essere ignorata. Invece, dovrebbe essere accoppiato con il resto delle informazioni utilizzate in questo post.<\/p>\n<h2>Esecuzione di test unitari<\/h2>\n<p>Nel prossimo post, ti guider\u00f2 attraverso tutto ci\u00f2 che devi sapere per configurare un file XML che informer\u00e0 PHPUnit di dove risiedono i test e come eseguirli.<\/p>\n<p>Per ora, per\u00f2, rivedi il codice che si trova in questo post e preparati a costruirlo nel prossimo post di questa serie.<\/p>\n<p><div id=\"PostUnique_PostSource\" style=\"padding-top: 50px\">Fonte di registrazione:  <a target=\"_blank\" rel=\"noopener nofollow\" href=\"\/\/tommcfarlin.com\" class=\"external external_icon\">tommcfarlin.com<\/a><\/div><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Un tutorial su come scrivere unit test che sfruttano correttamente i metodi setUp e tearDown di PHPUnit.<\/p>\n","protected":false},"author":1,"featured_media":164140,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[804,720,844],"tags":[1168],"class_list":["post-230648","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-php-6","category-sviluppatore","category-tutorial","tag-affiai-it"],"_links":{"self":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/230648","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/comments?post=230648"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/230648\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media\/164140"}],"wp:attachment":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media?parent=230648"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/categories?post=230648"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/tags?post=230648"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}