The /app directory was slimmed down, leaving in only the most essential parts of the application. Directories such as config, database, storage, and tests have been moved out of the app directory since they are auxiliary to the application itself. Most importantly, the integration of the testing tools has matured drastically.

Thanks to the efforts of the Framework Interoperability Group (PHP-FIG), the developer of the PHP Standard Recommendation (PSR), the reading, writing, and formatting of the framework code is becoming easier. It even allows developers to more easily work in more than one framework. Laravel is a part of the FIG and continues to adopt its recommendations into the framework. Laravel 5.1, for example, will adopt the PSR-2 standard. For more information about the PHP FIG and PSR, visit the PHP-FIG website, http://www.php-fig.org.

The basic process involves downloading and installing Composer and then adding Laravel as a dependency. An important detail is that the storage directory, which is located parallel to the /app directory, needs to be set in such a way that it is writable by the web server user in order to allow Laravel 5 to do things like writing the log files. It is also important to make sure that $ php artisan key:generate is used to generate a 32-character key that is used for hashing because, since the release of PHP 5.6, Mcrypt is more strict as regards its requirements. For Laravel 5.1, OpenSSL will replace Mcrypt.

In Laravel 4, the environments were configured in a manner that relied on the hostname of the server or a development machine, and this was rather contrived. Laravel 5 instead uses a .env file that sets up the various environments. This file is included in .gitignore. Thus, each machine should receive its configuration from a source outside the source code control.

So for example, something like the following code can be used to set up a local development:

APP_ENV=local
APP_DEBUG=true
APP_KEY=SomeRandomString
DB_HOST=localhost
DB_DATABASE=example
DB_USERNAME=DBUser
DB_PASSWORD=DBPass
CACHE_DRIVER=file
SESSION_DRIVER=file

A nice new feature of Laravel is that it allows you to set the highest level namespace to something such as MyCompany through the app:name command. This command will actually change the namespace of all the relevant files inside the /app directory from App to MyCompany, for example. This namespace then lives inside the /app directory. This builds namespacing right into virtually every file whereas previously, in version 4.x, it was optional.

The PHP port of the PHP testing software is named PHPUnit. Yet, test-driven development in the PHP language is a fairly recent concept. For example, in his book, "The Grumpy Programmer's Guide To Building Testable PHP Applications", which was published at the end of 2012, Chris Hartjes wrote "I started looking into the culture of testing surrounding CodeIgniter. It's weaker than a newborn baby."

Testing has been a part of the Laravel framework since version 3 that uses the PHPUnit unit-testing tool, and therefore Laravel's inclusion of the phpunit.xml file was a huge leap forward in the effort to encourage developers to embrace test-driven development.

The rules of test-driven development call for red, green, refactor, which means that once the tests pass (green), we should try to refactor or simplify the code inside the method without altering the functionality.

Have a look at the if test:

if ( $end->diffInDays($start) < 1 ) {

The preceding code isn't quite readable. We can refactor it in the following way:

if (!$end->diffInDays($start)>0)

However, even the preceding code is not very legible, and we are also using an integer directly in the code.

Let's move 0 into a constant. To improve the readability, we'll change it to the minimum amount of days required for a reservation, as follows:

 const MINIMUM_STAY_LENGTH = 1;

Let's extract the comparison into a method, as follows:

    /**
     * @param $end
     * @param $start
     * @return bool
     */
    private function endDateIsGreaterThanStartDate($end, $start)
    {
        return $end->diffInDays($start) >= MINIMUM_STAY_LENGTH;
    }

We can now write the if statement like this:

if (!$this->endDateIsGreaterThanStartDate($end, $start))

The preceding statement is much more expressive and readable.

Now, for the next rule, which states that a reservation cannot be made for more than fifteen days, we'll need to create the method in the following way:

function it_cannot_be_made_for_more_than_fifteen_days(User $user, $start_date, $end_date, Room $room)
{
        $start_date = '2015-06-01';
        $end_date = '2015-07-30';
        $rooms = [$room];
        $this->shouldThrow('\InvalidArgumentException')
        ->duringCreateNew( $user,$start_date,$end_date,$rooms);
}

Here, we set the $end_date so that it is assigned a date that occurs more than a month after the $start_date to cause the method to throw an InvalidArgumentException. Once again, upon execution of the phpspec command, the test will fail. Let's modify the existing method to check the date range. We'll add the following code to the method:

  if ($end->diffInDays($start)>15) {
       throw new \InvalidArgumentException('Cannot reserve a room
       for more than fifteen (15) days.');
  }

Once again, phpspec happily runs all the tests successfully. Refactoring, we will once again extract the if condition and create the constant, as follows:

   const MAXIMUM_STAY_LENGTH = 15;
   /**
     * @param $end
     * @param $start
     * @return bool
     */
    private function daysAreGreaterThanMaximumAllowed($end, $start)
    {
        return $end->diffInDays($start) > self::MAXIMUM_STAY_LENGTH;
    }

   if ($this->daysAreGreaterThanMaximumAllowed($end, $start)) {
            throw new \InvalidArgumentException ('Cannot reserve a room for more than fifteen (15) days.');
   }

We could leave things like this, but let's clean it up since we have tests. Since the endDateIsGreaterThanStartDate($end, $start) and daysAreGreaterThanMaximumAllowed($end, $start) functions both check for the minimum and maximum allowed stay respectively, we can call them from another method.

We will refactor endDateIsGreaterThanStartDate() into daysAreLessThanMinimumAllowed($end, $start) and then create another method that checks both the minimum and maximum stay length, as follows:

private function daysAreWithinAcceptableRange($end, $start)
    {
        if ($this->daysAreLessThanMinimumAllowed($end, $start)
            || $this->daysAreGreaterThanMaximumAllowed($end, $start)) {
           return false;
        } else {
           return true;
        }
    }

This leaves us with simply one function, instead of two, in the createNew function, as follows:

if (!$this->daysAreWithinAcceptableRange($end, $start)) {
            throw new \InvalidArgumentException('Requires a stay length from '
                . self::MINIMUM_STAY_LENGTH . ' to '. self::MAXIMUM_STAY_LENGTH . ' days.');
        }

For the third rule, which states that a reservation cannot contain more than four rooms, the process is the same. Create the specification, as follows:

it_cannot_contain_than_four_rooms

The change here will be in the parameters. This time, we will mock five rooms so that the test will fail, as follows:

function it_cannot_contain_than_four_rooms(User $user, $start_date, $end_date, Room $room1, Room $room2, Room $room3, Room $room4, Room $room5)

Five room objects will be loaded into the $rooms array, and the test will fail as follows:

$rooms = [$room1, $room2, $room3, $room4, $room5];
    $this->shouldThrow('\InvalidArgumentException')->duringCreateNew($user,$start_date,$end_date,$rooms);
    }

After adding code to check the size of the array, the final class will look like this:

<?php

namespace MyCompany\Accommodation;

use Carbon\Carbon;
class ReservationValidator
{

    const MINIMUM_STAY_LENGTH = 1;
    const MAXIMUM_STAY_LENGTH = 15;
    const MAXIMUM_ROOMS = 4;

    /**
     * @param $start_date
     * @param $end_date
     * @param $rooms
     * @return $this
     */
    public function validate($start_date, $end_date, $rooms)
    {
        $end = Carbon::createFromFormat('Y-m-d', $end_date);
        $start = Carbon::createFromFormat('Y-m-d', $start_date);

        if (!$this->daysAreWithinAcceptableRange($end, $start)) {
            throw new \InvalidArgumentException('Requires a stay length from '
                . self::MINIMUM_STAY_LENGTH . ' to '. self::MAXIMUM_STAY_LENGTH . ' days.');
        }
        if (!is_array($rooms)) {
            throw new \InvalidArgumentException('Requires last parameter rooms to be an array.');
        }
        if ($this->tooManyRooms($rooms)) {
            throw new \InvalidArgumentException('Cannot reserve more than '. self::MAXIMUM_ROOMS .' rooms.');
        }

        return $this;

    }

    /**
     * @param $end
     * @param $start
     * @return bool
     */
    private function daysAreLessThanMinimumAllowed($end, $start)
    {
        return $end->diffInDays($start) < self::MINIMUM_STAY_LENGTH;
    }

    /**
     * @param $end
     * @param $start
     * @return bool
     */
    private function daysAreGreaterThanMaximumAllowed($end, $start)
    {
        return $end->diffInDays($start) > self::MAXIMUM_STAY_LENGTH;
    }

    /**
     * @param $end
     * @param $start
     * @return bool
     */
    private function daysAreWithinAcceptableRange($end, $start)
    {
        if ($this->daysAreLessThanMinimumAllowed($end, $start)
            || $this->daysAreGreaterThanMaximumAllowed($end, $start)) {
            return false;
        } else {
            return true;
        }
    }

    /**
     * @param $rooms
     * @return bool
     */
    private function tooManyRooms($rooms)
    {
        return count($rooms) > self::MAXIMUM_ROOMS;
    }

    public function rooms(){
        return $this->belongsToMany('MyCompany\Accommodation\Room')->withTimestamps();
    }

}

The method is very clean. There are only two if statements—the first to verify that the date range is valid, and other one to verify that the number of rooms is within the valid range. The constants are easily accessible and can be changed as the business requirements change. Clearly, the addition of phpspec into the development workflow combines what earlier required two steps—writing the assertions with PHPUnit and then writing the code. Now, we will leave phpspec and move on to Artisan, which developers are familiar with as it was a feature of the previous versions of Laravel.

Laravel 5 has adopted the command bus pattern, which creates commands that get created in the app/Commands directory. Whereas commands in Laravel 4 were thought of as command-line tools, in Laravel 5, the command is thought of as a class whose methods can be used from within the application, allowing for an excellent reuse of code. The concept of a command here is a task that needs to be done, or in our example, a room to be reserved for a user. The paradigm of a bus then transports the command using the new DispatchesCommands trait, which is used in the base controller class. Every controller created by Artisan extends this class to a handler method, where the actual work is performed.

To use Laravel's command bus design pattern, we'll now use Artisan to create a few commands. We'll go into detail about commands in a future chapter, but to begin, we will type the following command:

$ php artisan make:commandReserveRoomCommand --handler

Typing this creates a command to reserve a room which could be called from anywhere in the code, isolating the business logic from the controllers and models, and also allowing the command to be executed in an asynchronous mode.

<?php namespace MyCompany\Commands;

use MyCompany\Commands\Command;

class ReserveRoomCommand extends Command {

    /**
    * Create a new command instance.
    *
    * @return void
    */
    public function __construct()
    {
        //
    }

}

After filling in the details of the command, the class will now look like this:

<?php namespace MyCompany\Commands;

use MyCompany\Commands\Command;
use MyCompany\User;

class ReserveRoomCommand extends Command {

    public $user;
    public $rooms;
    public $start_date;
    public $end_date;

    /**
    * Create a new command instance.
    *
    * @return void
    */
    public function __construct(User $user, $start_date, $end_date, $rooms)
    {
        $this->rooms = $rooms;
        $this->user = $user;
        $this->start_date = $start_date;
        $this->end_date = $end_date;
    }

}

The --handler parameter creates an additional class, ReserveRoomCommandHandler, containing a constructor and a handle method, which injects the ReserveRoomCommand. This file will be present in the app/Handlers/Commands directory. If the --handler flag is not used, then the ReserveRoomCommand class will contain its own handler method, and the separate handler class will not get created:

<?php namespace MyCompany\Handlers\Commands;

use MyCompany\Commands\ReserveRoomCommand;

use Illuminate\Queue\InteractsWithQueue;

class ReserveRoomCommandHandler {

    /**
    * Create the command handler.
    *
    * @return void
    */
    public function __construct()
    {
        //
    }

    /**
    * Handle the command.
    *
    * @paramReserveRoomCommand  $command
    * @return void
    */
    public function handle(ReserveRoomCommand $command)
    {
        //
    }

}

We will fill in the handle method with the validation of the reservation, as follows:

public function handle(ReserveRoomCommand $command)
    {
        $reservation = new \MyCompany\Accommodation\ReservationValidator();
        $reservation->validate(
        $command->start_date, $command->end_date, $command->rooms);
    }