Test-Driven Development con Laravel e Doctrine

() translation by (you can also view the original English article)

Da sviluppatore PHP, puoi usare la tecnica del Test-Driven Development (TDD) per sviluppare il tuo software scrivendo test. Solitamente, il TDD divide ciascuna attività dello sviluppo in unità individuali. Un test è quindi scritto per assicurare che l'unità si comporti come previsto.

Ogni progetto che utilizza il Test-Driven Development segue ripetutamente tre semplici step:

scrivi un test per il prossimo pezzo di funzionalità che vuoi aggiungere.
scrivi il codice funzionale fino a quando il test lo supera.
fai il refactoring sia del nuovo che del vecchio codice per renderlo ben strutturato.

Continua a ciclare questi tre step, un test alla volta, realizzando la funzionalità del sistema. Testare ti aiuterà nel refactoring, azione che consente di migliorare il progetto col tempo e rende alcuni problemi di progettazione più evidenti.

I test che contengono piccoli componenti individuali sono chiamati unit test (test unitari). Sebbene gli unit test possano essere portati a termine indipendentemente, se testi alcuni componenti quando sono integrati in altri, stai facendo integration testing (test di integrazione). Il terzo tipo di testing è il test stubs. Il test stubs ti permette di testare il codice senza avere chiamate reali al database.

Perché TDD Funziona

Al giorno d'oggi, visto che puoi usare la sintassi dei moderni IDE PHP, il feedback non è un grosso problema. Uno degli aspetti importanti dello sviluppo è essere certi che il codice si comporti come previsto. Dato che il software è complesso (differenti componenti integrati gli uni agli altri), è facile che molte delle nostre aspettative vengano disattese. Specialmente alla fine del progetto, a causa dello sviluppo, il progetto diventa più complicato e quindi più difficile da debuggare e testare.

Il TDD verifica che il codice faccia quello che ci si aspetta. Se qualcosa va male, ci sono solo poche linee di codice da ricontrollare. Gli errori sono facili da trovare e da correggere. Nel TDD, il test si focalizza sul comportamento, non sull'implementazione. Il TDD produce codice che è stato progettato, testato e collaudato.

PHPUnit e Laravel

PHPUnit è lo standard di fatto per lo unit testing in PHP. È essenzialmente un framework per scrivere test e fornisce gli strumenti di cui hai bisogno per eseguire i test e analizzare i risultati. PHPUnit trae la sua struttura e funzionalità dall' SUnit di Kent Beck.

Esistono molte differenti asserzioni che possono aiutarti a testare i risultati di tutte le possibili chiamate nelle applicazioni. A volte occorre essere un po' più creativi per testare parti funzionali più complesse, ma le asserzioni fornite da PHPUnit coprono la maggior parte delle situazioni da testare. Ecco una lista delle più comuni che incontrerai e che userai nei test.

AssertTrue: controlla l'input per verificare che sia uguale a true.
AssertFalse: controlla l'input per verificare che sia uguale a false.
AssertEquals: controlla il risultato con un input per verificare se sono uguali.
AssertArrayHasKey: restituisce un errore se nell'array non c'è la chiave ricercata.
AssertGreaterThan: controlla il risultato per vedere se è più grande di un valore.
AssertContains: controlla che l'input contenga un determinato valore.
AssertType: controlla che una variabile sia di un certo tipo.
AssertNull: controlla che una variabile sia null.
AssertFileExists: verifica che un file esista.
AssertRegExp: controlla che l'input soddisfi un'espressione regolare.

Di default, PHPUnit 4.0 è già installato in Laravel e potrebbe essere necessario lanciare il seguente comando per aggiornarlo:

1	composer global require "phpunit/phpunit=5.0.*"

Il file phpunit.xml, nella directory root di Laravel, ti consente di effettuare alcune configurazioni. In questo caso, se vuoi sovrascrivere la configurazione di default, puoi editare il file.

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="bootstrap/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false"
         syntaxCheck="false">
    <testsuites>
        <testsuite name="Application Test Suite">
            <directory>./tests/</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist>
            <directory suffix=".php">app/</directory>
        </whitelist>
    </filter>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="QUEUE_DRIVER" value="sync"/>
        <env name="DB_DEFAULT" value="sqlite_testing"/>
        <env name="DB_HOST" value="localhost"/>
        <env name="DB_DATABASE" value="laravel"/>
        <env name="DB_USERNAME" value="root"/>
        <env name="DB_PASSWORD" value="root"/>
    </php>
</phpunit>


Come puoi vedere dal codice sopra, ho aggiunto la configurazione del database di prova (non usato nell'articolo).

Cos'è l'ORM Doctrine?

Doctrine è un ORM che implementa il pattern data mapper e consente di creare una netta separazione tra la logica dell'applicazione e il persistence layer del database. Per usare Doctrine, esiste un'implementazione da utilizzare con una configurazione esistente di Laravel 5. Per installare Doctrine 2 nel tuo progetto Laravel, esegui il seguente comando:

1	composer require laravel-doctrine/orm

Come di consueto, il package dovrebbe essere aggiunto alla lista dei service provider in app/config.php.

1	LaravelDoctrine\ORM\DoctrineServiceProvider::class,

Devi configurare anche l'alias:

1	'EntityManager' => LaravelDoctrine\ORM\Facades\EntityManager::class

Infine, pubblichiamo la configurazione del package con:

1	php artisan vendor:publish --tag="config"

Come Testare i Repository di Doctrine

Prima di qualsiasi altra cosa, dovresti approfondire le fixture. Le fixture sono usate per caricare in un database un limitato set di dati da testare. Fortunatamente, Doctrine 2 fornisce una libreria per aiutarti a scrivere le fixture per l'ORM Doctrine.

Per installare il bundle delle fixture nella tua App Laravel, abbiamo bisogno di eseguire il seguente comando:

1	composer require --dev doctrine/doctrine-fixtures-bundle

Creiamo la nostra fixture in tests/Fixtures.php:

namespace Test;
use Doctrine\Common\Persistence\ObjectManager;
use Doctrine\Common\DataFixtures\FixtureInterface;
use app\Entity\Post;

class Fixtures implements FixtureInterface
{
    /**
     * Load the Post fixtures
     * @param ObjectManager $manager
     * @return void
     */
    public function load(ObjectManager $manager)
    {
        $Post = new Post(['title'=>'hello world','body'=>'this is body']);
        $manager->persist($Post);
        $manager->flush();
    }
}


Come puoi osservare, la classe fixture deve implementare la FixtureInterface e deve avere il metodo load(ObjectManager $manager). Le fixture di Doctrine 2 sono classi PHP in cui puoi creare oggetti e renderli persistenti nel database. Per fare l'autoload delle nostre fixture, in Laravel, dobbiamo modificare il file composer.json nella root di Laravel.

...
    "autoload-dev": {
        "classmap": [
            "tests/TestCase.php",
            "tests/Fixtures.php" //added here
        ]
    },
...

Esegui quindi:

1	composer dump-autoload

Creiamo il nostro file di test DoctrineTest.php nella directory tests.

namespace Test;
use App;
use App\Entity\Post;
use Doctrine\Common\DataFixtures\Executor\ORMExecutor;
use Doctrine\Common\DataFixtures\Purger\ORMPurger;
use Doctrine\Common\DataFixtures\Loader;
use App\Repository\PostRepo;

class doctrineTest  extends TestCase
{
    private $em;
    private $repository;
    private $loader;
    public function setUp()
    {
        parent::setUp();
        $this->em = App::make('Doctrine\ORM\EntityManagerInterface');
        $this->repository = new PostRepo($this->em);
        $this->executor = new ORMExecutor($this->em, new ORMPurger);
        $this->loader = new Loader;
        $this->loader->addFixture(new Fixtures);
    }

    /** @test */
    public function post()
    {
        $purger = new ORMPurger();
        $executor = new ORMExecutor($this->em, $purger);
        $executor->execute($this->loader->getFixtures());
        $user = $this->repository->PostOfTitle('hello world');
        $this->em->clear();
        $this->assertInstanceOf('App\Entity\Post', $user);
    }
}

Nel metodo setUp(), ho instanziato l'ORMExecutor e il Loader. Carichiamo anche la classe Fixtures che abbiamo appena implementato.

Non dimenticare che l'annotazione /** @test */ è molto importante, e senza di essa phpunit restituirebbe l'errore No tests found in class.

Per iniziare il test nella root del progetto, esegui semplicemente il comando:

1	sudo phpunit

Il risultato sarà:

PHPUnit 4.6.6 by Sebastian Bergmann and contributors.

Configuration read from /var/www/html/laravel/phpunit.xml.
Time: 17.06 seconds, Memory: 16.00M
OK (1 test, 1 assertion)

Se devi condividere oggetti tra le fixture, puoi farlo aggiungendo semplicemente una referenza a quell'oggetto dandogli un nome e richiamandolo successivamente per formare una relazione. Ecco un esempio:

namespace Test;
use Doctrine\Common\Persistence\ObjectManager;
use Doctrine\Common\DataFixtures\FixtureInterface;
use app\Entity\Post;

class PostFixtures implements FixtureInterface
{
    /**
     * Load the User fixtures
     *
     * @param ObjectManager $manager
     * @return void
     */
    public function load(ObjectManager $manager)
    {
        $postOne = new Post(['title'=>'hello','body'=>'this is body']);
        $postTwo = new Post(['title'=>'hello there ','body'=>'this is body two']);
        $manager->persist($postOne);
        $manager->persist($postTwo);
        $manager->flush();

        // store reference to admin role for User relation to Role
        $this->addReference('new-post',$postOne);
    }
}

e la fixture Comment:

namespace Test;
use Doctrine\Common\Persistence\ObjectManager;
use Doctrine\Common\DataFixtures\FixtureInterface;
use app\Entity\Post;

class CommentFixtures implements FixtureInterface
{
    /**
     * Load the User fixtures
     *
     * @param ObjectManager $manager
     * @return void
     */
    public function load(ObjectManager $manager)
    {
        $comment = new Comment(['title'=>'hello','email'=>'alirezarahmani@live.com','text'=>'nice post']);
        $comment->setPost($this->getReference('new-post')); // load the stored reference
        $manager->persist($comment);
        $manager->flush();
        // store reference to new post for Comment relation to post
        $this->addReference('new-post',$postOne);
    }
}

Con i due metodi getReference() e setReference(), puoi condividere uno o più oggetti tra le fixture.

Se per te è importante ordinare le fixture, puoi farlo semplicemente con il metodo getOrder nelle tue fixture, come mostrato qui di seguito:

1	public function getOrder()
2	{
3	return 5; // number in which order to load fixtures
4	}

Presta attenzione al fatto che l'ordinamento è rilevante per la classe Loader.

Una delle cose più importanti delle fixture è la loro capacità di risolvere problemi di dipendenze. L'unica cosa che devi aggiungere è un metodo nella tua fixture, come ho fatto qui sotto:

1	public function getDependencies()
2	{
3	return array('Test\CommentFixtures'); // fixture classes fixture is dependent on
4	}

Conclusioni

Questa è solo un accenno al Test-Driven Development con Laravel 5 e PHPUnit. Nel test dei repository, è inevitabile che si utilizzi il database. In questo caso, le fixture di Doctrine sono importanti.