# Test Driven Development

• Data articolo: 31/01/2020

Per contribuire alla diffusione di una pratica essenziale e fondamentale come è quella del Test Driven Development (TDD), prendo ad esempio il codice del pacchetto Marketing (luca-pezzino/marketing-admin), del mio ultimo progetto Luca Pezzino E-commerce. Il TDD, traduce l'esigenza del business in codice e guida passo a passo alla codifica della stessa, in maniera certificata e garantita per sempre (nei deploys, tutti i tests possono essere continuamente fatti girare automaticamente).

Come si deduce dal titolo stesso della classe, si tratta dei tests che hanno reso possibile l'implementazione dei saldi: qui limito l'analisi del codice al primo test, la creazione di un saldo (il codice è una porzione dell'originale, non riporto ad esempio i tests per la validazione dei dati passati all'endPoint).

class CRUDSaleTest extends TestCase
{
    /**
    * it can create a sale
    *
    * @test
    */
    public function it_can_create_a_sale()
    {
        //Given
        $sale = factory(Sale::class)->make()->toArray();
        $this->setUrl('/sales')
            ->setHttpMethod('POST')
            ->setPayload($this->getSalesRelationshipsData() + $sale);

        $this->assertDatabaseMissing('sales', $sale);
        $this->callEndPoint()->assertUnauthenticated();
        $authorizedUser = $this->createAuthorizedUser('I cannot create sales');
        $this->callEndPoint()->assertUnauthorized();

        $this->setPermissionTo('create sales', $authorizedUser);

        //When
        $this->callEndPoint();

        //Then
        $this->response->assertCreated();
        $this->assertDatabaseHas('sales', $sale);
    }

    /**
    * it can lists all the sales
    *
    * @test
    */
    public function it_can_lists_all_the_sales()
    {
    }

    /**
    * it can show a sale
    *
    * @test
    */
    public function it_can_show_a_sale()
    {
    }

    /**
    * it can update a sale
    *
    * @test
    */
    public function it_can_update_a_sale()
    {
    }

    /**
    * it can delete a sale
    *
    * @test
    */
    public function it_can_delete_a_sale()
    {
    }
}

Il nome della Classe e dei suoi metodi, fungono anche da documentazione per il progetto, utilissima per eventuali nuovi programmatori che subentrano in aggiunta/sostituzione al team. Probabilmente persino chi non è programmatore, comprende le funzionalità che si intendono implementare in questo package.

Nelle poche righe del codice, oltre ad assicurarmi che si possa creare un saldo, proteggo l'endPoint da chi non è autenticato e da chi è autenticato ma non ha sufficenti autorizzationi. Il codice è un esempio di Feature Test (o Integration Test) e testa varie parti dell'applicazione: qui sono stati coinvolti Routers, Controllers, Models e database.

La struttura del test Given/When/Then (preparazione e pre-condizioni/lancio del comando/verifica del risultato) è anche nota come Arrange/Act/Assert.

# Conclusione

In questo breve blog, auspico di essere riuscito a rendere più evidente la necessità di non poter sviluppare senza TDD. I vantaggi sono troppo importanti per essere trascurati:

• documentazione per nuovi sviluppatori
• certificazione che il codice sia eseguito correttamente e quindi
  • permettere refactoring in sicurezza
  • permettere upgrade del framework
  • garantire che aggiunte o modifiche al progetto, non vadano ad invalidare features anche non strettamente connesse

I vantaggi sono innegabili: chi si ostina a non usare il TDD, si assicura prima o poi, problemi più o meno gravi con i propri clienti.