# Test Driven Development

• Article date: January 31, 2020

To contribute to the spread of a essential and fundamental practice such as that of Test Driven Development (TDD), let's take for example the code of the "Marketing" package, of my latest project Luca Pezzino E-commerce. The TDD translates the business'need into code and guides it step by step to coding it, in a certified and guaranteed way forever (in the deploys, all tests can be continuously run automatically).

As can be deduced from the class title itself, these are the tests that made it possible to implement a sale: here I limit the analysis of the code (partially taken from the original, for example I do not report here tests for the validation of data passed to the endPoint) limited to the first test, the creation of a sale.

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()
    {
    }
}

The name of the Class and its methods also act as documentation for the project, very useful for any new programmers who take over in addition / replacement to the team. Probably even those who are not programmers understand the features that are intended to be implemented in this package.

In the few lines of the code, in addition to making sure that a sale can be created, I protect the endPoint from those who are not authenticated and from those who are authenticated but do not have sufficient authorizations. The code is an example of a Feature Test (or Integration Test) and tests various parts of the application: here Routes, Controllers, Models and databases have been involved.

The structure of the Given/When/Then test (preparation and pre-conditions/launch of the command/verification of the result) is also known as Arrange / Act / Assert.

# Conclusion

In this short blog, I hope to make more evident the need to develop with TDD. The benefits are too important to be overlooked:

• documentation for new developers
• certification that the code is correctly executed and therefore
  • allow refactoring in safety
  • allow framework upgrades
  • ensure that additions or changes to the project do not invalidate features, even if not strictly connected

The advantages are undeniable: whoever insists on not using the TDD, ensures sooner or later, more or less serious problems with their customers.