An integral part of writing high quality web applications is having automated tests that can ensure that your entire application is functioning correctly. In a Continuous Integration (CI) set up, having automated tests is extremely important to ensure that new changes don’t break the current code.

This isn’t a tutorial on Test Driven Development, so I’m going to assume that you already know what it is, how it is structured and what we are trying to achieve. If this is all new to you, take a look at my tutorial What is Test Driven Development?.

If you haven’t already read last week’s tutorial, you will probably want to read that first as it gives a lot of background to what I’m going to be doing in this tutorial, Setting up your first Laravel 4 Model.

Installing PHPUnit

In order to write automated tests, we need to install a fantastic package called PHPUnit.

If you are new to PHPUnit, you might want to read my introductory tutorial Getting started with PHPUnit first.

To install PHPUnit, add the following line to your composer.json file.

{
  "require-dev": {
    "phpunit/phpunit": "3.7.*"
  }
}

Next run the composer update command to install the package:

$ composer update

Now that you have PHPUnit installed, you can run automated tests from the command line. Laravel comes with one example test already set up. To make sure you have PHPUnit correctly set up, run the following command from Terminal:

$ vendor/bin/phpunit

You should get the following line returned if everything went ok:

OK (1 test, 2 assertions)

To make things easier for myself, I like to set an alias to PHPUnit so I don’t have to type of the vendor/bin bit every time I want to run the command.

alias phpunit='vendor/bin/phpunit'

Writing your first test

When writing unit tests, you want to concentrate on only one thing in particular. So for each Model that you have in your system, you should have exactly one test file that contains all of the automated tests. If you find yourself writing tests for things in more than one place, you will probably be doing something wrong.

All of the tests in a Laravel application are kept under app/tests.

If you look inside that directory, you should find the ExampleTest.php. When we ran the phpunit command from the command line earlier, this is the file of tests that was run. As you can see, there is one test with 2 assertions. You can just delete this file.

Laravel doesn’t force you to structure your tests directory in any particular way. You can keep all of your tests under the tests directory, or you can put them in more specific sub folders. I’m going to be putting my tests in sub folders for Models and Controllers, but I might change this in the future. For example, a common structure is to separate your test files into unit, functional and integration directories, but at the end of the day, it doesn’t really matter.

So create a new directory called models app/tests/models and create a new file under that directory called UserTest.php.

Copy the following code to create your User Test file:

class UserTest extends TestCase {}

As you can see, a test is simply a class that extends from the TestCase class. If you look under the app/tests directory, you will see the TestCase.php file that we are extending from. This is simply how Laravel sets up the testing environment and extends from PHPUnit so that we can write tests with all of the right methods. You don’t need to worry about this, just make sure that all of your test classes extend from TestCase and everything will automatically work correctly.

Each individual test should be written as a public method. The name of the method should be a descriptive name of what you are testing for. For example:

public function testThatTrueIsTrue()
{
  $this->assertTrue(true);
}

If you run phpunit once again you will see that this test passed successfully with one assertion.

OK (1 test, 1 assertion)

Setting up the test environment database

As I mentioned in my Migration tutorial, Laravel makes it incredibly easy to switch out databases. This means for example, we can use a different database when in the testing environment, but we don’t actually have to change any of our code.

Under the app/config/testing directory, create a new file called database.php and copy the following configuration details:

<?php
return array(
  'default' => 'sqlite',
  'connections' => array(
    'sqlite' => array(
    	'driver'   => 'sqlite',
    	'database' => ':memory:',
    	'prefix'   => ''
  	),
  )
);

Now whenever your application is in the testing environment, Laravel will automatically use the SQLite in-memory database instead of hitting your actual database.

Why is this such a good thing? Testing with an in-memory database is much quicker than hitting an actual database. It also prevents the problem of having left over test data in your database every time you run your tests.

Next we need to hijack the TestCase class to finish off the set up for using an in-memory database. This is because we need to migrate the database at the start of each test because the database will be empty to begin with.

Add the following two methods to your TestCase class:

<?php
class TestCase extends Illuminate\Foundation\Testing\TestCase {
 
  /**
   * Default preparation for each test
   */
  public function setUp()
  {
    parent::setUp();
 
    $this->prepareForTests();
  }
 
  /**
   * Creates the application.
   *
   * @return Symfony\Component\HttpKernel\HttpKernelInterface
   */
  public function createApplication()
  {
    $unitTesting = true;
 
    $testEnvironment = 'testing';
 
    return require __DIR__.'/../../start.php';
  }
 
  /**
   * Migrate the database
   */
  private function prepareForTests()
  {
    Artisan::call('migrate');
  }
}

I discovered this technique after reading this fantastic post Testing Like a Boss in Laravel: Models by Zizaco Zizuini. We will be using more of Zizaco’s packages over the course of creating Cribbb, so go and checkout his work and give him mad props for being an awesome contributor to the Laravel community.

Testing the User Model

Now that we have everything set up, we can start writing some tests. Currently our User model only really has validation that we can write tests for.

The first thing we will test for is that a username is a required field:

/**
 * Username is required
 */
public function testUsernameIsRequired()
{
  // Create a new User
  $user = new User;
  $user->email = "phil@ipbrown.com";
  $user->password = "password";
  $user->password_confirmation = "password";

  // User should not save
  $this->assertFalse($user->save());

  // Save the errors
  $errors = $user->errors()->all();

  // There should be 1 error
  $this->assertCount(1, $errors);

  // The username error should be set
  $this->assertEquals($errors[0], "The username field is required.");
}

So first we create a new user that does not have a username.

Next, we attempt to save the user and we assert that the return value is false.

Next, we grab the errors and we make sure there is only one.

And finally we assert that the correct error has been set.

Now if you run PHPUnit again, you should get the following response:

$ phpunit
$ OK (1 test, 3 assertions)

And that is how you would write a validation test for the username property of the User model. Now strictly speaking, you shouldn’t have to write tests for your validation because we are using the Ardent package that will already have these tests. But, I think writing validation tests is a nice and easy way to get into thinking in the mindset of Test Driven Development.

Conclusion

That was an introductory tutorial on setting up your automated tests in a Laravel project. Hopefully you now have a good understanding on why you need automated tests as well as how to structure them and how to run them.

A good analogy for automated testing is that it is like having breaks on your car. If a car didn’t have breaks, the driver would have to drive very slowly because it would be dangerous. Automated testing allows you as a developer to work much quicker because it provides you with a safety net if something goes wrong.

This is a series of posts in building an entire Open Source application called Cribbb. All of the tutorials will be free to web, and all of the code is available on GitHub.

So far I’ve covered:

1. Getting started with Laravel 4
2. Laravel 4 Migrations
3. Setting up your first Laravel 4 Model

In next Monday’s tutorial we will be looking at writing more advanced automated tests using fixtures!

Getting started with testing Laravel 4 Models was written by Philip Brown on Culttt - Articles on business, technology and the Internet

Laravel 4 is one such framework that uses the MVC design pattern to cleanly separate the various aspects of a web application.

In this post we’re going to look at what exactly is a Model, what are the three crucial components of Business Logic, and how to set up your first Model in Laravel 4.

What is a Model

So what exactly is a Model? If we’re going to be building this entire application on Models, first we need to understand exactly what they are.

A Model should contain all of the Business Logic of your application. Or in other words, how the application interacts with the database.

Business Logic is essentially:

1. The real world objects that appear in your application
2. How those objects interact with each other
3. A set of rules for how those objects are accessed and updated

So for example, Users will be an important object within Cribbb because it is a social application.

1. We need to store details of our users and so we need a User Model and a User table in the database.
2. Users will be required to enter a username, email address and password as well as other profile details. In order to ensure they enter correctly formatted data, we need to validate their input.
3. Users will be able to create Posts. So a User can have many posts, and each Post should belong to a User.

So as you can see, that is basically how Models work in MVC applications. Essentially each important thing in the application will probably need a Model. You will probably need to validate the data that is used in your Models, and any logic that relates Models to one another should be dealt with here.

Creating the User model

User authentication is a requirement in just about every modern web application. Instead of forcing you to write your own User Model, Laravel 4 actually comes with a User Model straight out of the box.

So if you go into the app/models directory, you should find the User.php file. All of your models should go into this folder and they should be named following the same convention. So say for example, you had a Model for Posts in your application, the Model file would be app/models/Post.php.

As a side note, you don’t have to follow this convention, there are ways around it, but I really don’t know why you would.

Anyway, if you open up the User model, you will see a fairly basic Model boilerplate.

Anatomy of a Laravel Model

So as I mentioned above, every Model should represent a table in the database. In order to interact with the database, we will need to extend the Model from Eloquent. Eloquent is an ActiveRecord implementation that comes with Laravel.

Each Model extends Eloquent and so it inherits all of Eloquent’s methods for interacting with the database:

class User extends Eloquent {}

You will also notice that the default User Model implements two interfaces:

implements UserInterface, RemindableInterface

I’m not going to cover interfaces or the remindable features that are built into Laravel’s User model today as I will talk about them more extensively in a later tutorial.

The next thing you will notice is the protected property $table:

/**
 * The database table used by the model.
 *
 * @var string
 */
protected $table = 'users';

As you can probably guess, this is simply declaring the name of the table that this model refers to. By default you don’t need to set this property as Laravel follows the convention of configuration mantra. This basically means, if you call your model User, then Laravel will assume that your table name is users. Setting the $table property is useful when you want to give a table a name that does not follow this convention.

The $hidden property allows you to hide certain columns when returning an instance of the Model:

/**
 * The attributes excluded from the model's JSON form.
 *
 * @var array
 */
protected $hidden = array('password');

This is simply an array of column names. This is useful when you want to return details of the user over a JSON API for example. You wouldn’t want to display the user’s password.

Next we need to protect against mass assignment. When you pass an array of data to the Model, the data is automatically mass assigned to the right columns. This is handy because it makes things a lot easier, but it also presents quite a serious security concern. For example, you wouldn’t want the a user to be able to change their user id as this should set automatically when the user is created and it should never change.

To protect against mass assignment, we need to specify which of the columns can be mass assigned. To do this, we need to set the $fillable property.

protected $fillable = array('username', 'email');

This ensures only these fields can be mass assigned.

You can also set the $guarded property which prevents the listed columns from mass assignment. For example:

protected $guarded = array('id', 'password');

And finally, the model comes with three simple methods for returning specific data items from the Model:

/**
 * Get the unique identifier for the user.
 *
 * @return mixed
 */
public function getAuthIdentifier()
{
  return $this->getKey();
}

/**
 * Get the password for the user.
 *
 * @return string
 */
public function getAuthPassword()
{
  return $this->password;
}

/**
 * Get the e-mail address where password reminders are sent.
 *
 * @return string
 */
public function getReminderEmail()
{
  return $this->email;
}

Validating in your Model

All good applications require validating data at some point. Users are prone to make mistakes or enter incorrect data, and so you need to ensure that you enforce that only correct data is allowed to enter your system.

Laravel 4 comes with a fantastic Validation package that makes creating and enforcing validation rules incredibly easy.

However, Laravel 4 does not enforce that you put your validation in your Models. A common bad practice is to place validation in the controller. This is bad because you are more than likely going to have to repeat that validation in multiple places throughout your application.

A much better place for your Validation is inside your Model because all interactions with the database must go through the Model, and so you will only need to write your rules once.

Due to Laravel 4 not enforcing where you put your Validation logic, I’m going to use an excellent package called Ardent to handle all of that. Ardent allows you to create self-validating Models. This basically means, your Models will validate themselves whenever you interact with them so you don’t have to write validation logic.

Installing Ardent through Composer

Ardent is a Composer package so we can install it by simply adding it to the composer.json file.

Add the following line:

{
  "require": {
    "laravelbook/ardent": "dev-master"
  }
}

And then run the following to update your project:

$ composer update

Validating Models using Ardent

In order to use Ardent, first we need to change where the User Model extends from.

Extending from Ardent

In User.php you will need to update the following two lines:

// Add this line
use LaravelBook\Ardent\Ardent;

// Update this line
class User extends Ardent implements UserInterface, RemindableInterface {

Don’t worry through, all of Eloquent’s methods are still available through Ardent because Ardent is a direct decedent from Eloquent.

Validation rules

The next thing we need to do is to create a set of validation rules for each of the fields of the Model.

/**
 * Ardent validation rules
 */
public static $rules = array(
  'name' => 'required|between:4,16',
  'email' => 'required|email',
  'password' => 'required|alpha_num|min:8|confirmed',
  'password_confirmation' => 'required|alpha_num|between:4,8',
);

Ardent leverages Laravel’s Validation class to create these easy to use validation rules. The validation rules for your model are simply stored as a public static array. As you can see from the values of the array, each rule is separated with a pipe.

For a full list of available validation rules, see this section of the documentation.

Using Ardent’s validation

As I mentioned in the description of Ardent, all of your models will be “self validating”. This means your models will automatically reject input that does not pass your validation rules, without you actually having to do anything:

For example, the following will fail because I’m not supplying a password confirmation:

$user = new User;
$user->username = 'philipbrown';
$user->email = 'phil@ipbrown.com';
$user->password = 'deadgiveaway';
$user->save(); // returns false

However, the following will save successfully:

$user = new User;
$user->username = 'philipbrown';
$user->email = 'phil@ipbrown.com';
$user->password = 'deadgiveaway';
$user->password_confirmation = 'deadgiveaway';
$user->save(); // returns true

Notice how you don’t have to validate any of the data yourself? If the validation fails, the model will simply not save.

Automatically purge redundant data

We don’t really want to save the password_confirmation data as this is just used for validation. To tell Ardent to just get rid of the redundant data like confirmation fields, we need to add the following line to the User model.

public $autoPurgeRedundantAttributes = true;

Validation example in action

To quickly set up an example of all of this, we can simply define a new route that we can hit to see it in action.

Open app/routes.php and copy the following code:

Route::get('/user', function()
{
  $user = new User;
  $user->username = 'philipbrown';
  $user->email = 'phil@ipbrown.com';
  $user->password = 'deadgiveaway';
  $user->password_confirmation = 'deadgiveaway';
  var_dump($user->save());
});

This will simply create a new route that you can hit in the browser. When you go to /user, Laravel will automatically create a new user and attempt to save it to the database. If the user is saved correctly, you should see boolean true outputted to the screen.

Save your routes.php and run the following command in Terminal to quickly set up the server:

$ php artisan serve

Now go to http://localhost:8000/user to see your validation in action.

That was a very quick introduction to validating your Models in Laravel 4. I’ll be writing a much more in-depth article on the nitty gritty details of validation in the coming weeks.

Laravel model relationships

The third and final characteristic of a model is that they hold the information that describes how business objects interact with one another.

Describing the relationship of two models is as easy as creating a new method.

Add the following method to your User.php Model.

/**
 * Post relationship
 */
public function posts()
{
  return $this->hasMany('Post');
}

This extremely simple method is all you need to write in order to say a user has many posts.

Now of course, you will need to create the Post Model in order for this to work. I’m not going to go over creating the Post migration and model. Instead refer back to my Laravel 4 Migrations tutorial. For my Post model, I’m simply creating a body column and a user_id column. Here is the migration command that I ran.

php artisan generate:migration create_posts_table --fields="body:text, user_id:integer"

So your basic Post Model should look like this:

class Post extends Eloquent {

  protected $fillable = array('body');

  public function user()
  {
    return $this->belongsTo('User');
  }
  
}

Notice how I have set the inverse of the relationship in the user() method. This is simply saying that each post belongs to a user.

Next, create a new test route in your app/routes.php and paste the following:

// Create a new Post
$post = new Post(array('body' => 'Yada yada yada'));
// Grab User 1
$user = User::find(1);
// Save the Post
$user->posts()->save($post);

Now if you look in the posts table in your database, you should see that the post has saved and the user_id has automatically been assigned to the user’s id.

That was a very quick overview of creating relationships in your Laravel Models. Again, I will cover each of these areas in more detail as we add some complexity to Cribbb. To read more about Laravel Model relationships, have a look at the documentation.

Conclusion

That was a quick overview of how to create Laravel Models. Hopefully you should have a firm understanding of the three important aspects of business logic that should be dealt with within your Models.

As I’ve mentioned a couple of times in this post, in future tutorials I will be going into much more depth on some of the intricacies of how Models work in web applications.

The observant amongst you will have noticed that I haven’t strictly followed Test Driven Development. However, don’t worry, I will be covering how to write Model tests using PHPUnit next week!

This is a series of posts in building an entire Open Source application called Cribbb. All of the tutorials will be free to web, and all of the code is available on GitHub.

So far I’ve covered:

1. Getting started with Laravel 4
2. Laravel 4 Migrations

Come back next Monday as I look at how to write automated tests for your Models!

Setting up your first Laravel 4 Model was written by Philip Brown on Culttt - Articles on business, technology and the Internet

For example, say one of your colleagues adds a new feature, and in doing so, is required to add a new column to the database. They commit their code to Git and then push it to the repo. The next time you go to work on the project you pull the latest code down but you end up with a load of errors and a broken application because your database schema is now out of date.

Passing around a SQL dump is a horrible makeshift solution and it is totally inadequate for updating the production server because it causes downtime and things can go wrong due to human error.

Fortunately, Migrations are the answer to all of these problems.

What are Migrations?

Migrations are essentially a way to version control your database. Migrations are a series of timestamped instructions for making changes to your database. This allows you to record the changes you make to the schema so anyone else can simply run the instruction file to update their version of the database to keep things consistent. It also allows you to roll back any changes you have made to a database in the event that you made a mistake.

Even if you aren’t working with other developers, Migrations are really an essential part of building an application because it means you no longer have to write SQL or deal with a janky interface like phpMyAdmin. It also makes shipping live code much less stressful because you don’t have to worry about making changes to the live database.

If you have never used Migrations before, it can be kind of weird to think that you need them. But in all honesty, once you start using them, you will never go back.

Using Migrations in Laravel 4

Laravel 4 comes ready with Migrations out of the box. Using the artisan command line interface you can create new migrations just by running a single command.

However, in this tutorial we will be making our lives even easier by installing a fantastic package for Laravel Generators.

So here’s how to set up Migrations in Laravel 4.

Setting up the database

The first thing we need to do is to set up the database. Laravel provides you with a simple configuration file to save your database details, username and password.

Firstly, set up a new local database and create a new user. Next go to app/config/database.php and fill in your database details in the connections array.

  'mysql' => array(
    'driver'    => 'mysql',
    'host'      => 'localhost',
    'database'  => 'cribbb',
    'username'  => 'cribbb',
    'password'  => '',
    'charset'   => 'utf8',
    'collation' => 'utf8_unicode_ci',
    'prefix'    => '',
  ),

Notice how easy it is to switch the type of database that you are using. All you would have to do is to change the default value.

Installing Laravel 4 Generators

Although Laravel 4 comes with Migrations out of the box, we can make them even easier by using the Laravel 4 Generator package by Jeffrey Way.

First, open up your composer.json and add the Laravel 4 Generator package as a requirement:

"require": {
  "laravel/framework": "4.0.*",
  "way/generators": "dev-master"
}

Next, update Composer from the Terminal:

$ composer update

Finally, go into app/config/app.php and add the following line at the end of the providers array:

'Way\Generators\GeneratorsServiceProvider'

Now if you run php artisan from the command line you should see the new generator tasks.

How do Migrations work?

Migrations are basically just a set of timestamped instruction files that can be automatically run to modify a database. A migration file contains a class which have a series of SQL based methods for adding tables, updating columns or dropping a table all together.

In the migration file you will find an up method and a down method. This allows the migration file to make changes to a database, but also roll back those changes if it is required.

When a migration is run, it is recorded in a special migrations table in your database. This means Laravel knows which migrations have already run, and which are still needed to run to bring the database up to speed.

To create the migrations table, run the following command from Terminal:

$ php artisan migrate:install

If you now look in your database, you should see the new migrations table.

Creating a Migration

Cribbb is going to be a social application so we need a table to store details of our users. In order to do that, we need to create a migration to create the users table.

To create the Migration, run the following line from the command line:

$ php artisan generate:migration create_users_table --fields="email:string, password:string"

Now if you look under the app/database/migrations directory, you should see the new timestamped Migration file.

The anatomy of a Migration

When you run the Migration command above, Laravel will understand that you want to create a table called users. The fields option allows us to create fields for the table, in this case two fields called email and password which are both VARCHAR (which just means string).

Now if you look in the generated Migration file, you should have the following:

class CreateUsersTable extends Migration {

  /**
   * Run the migrations.
   *
   * @return void
   */
  public function up()
  {
    Schema::create('users', function(Blueprint $table) {
      $table->increments('id');
      $table->string('email');
      $table->string('password');
      $table->timestamps();
    });
  }

  /**
   * Reverse the migrations.
   *
   * @return void
   */
  public function down()
  {
    Schema::drop('users');
  }
}

Basically, all a Migration is, is a class with up and down methods. When the Migration is run, the instructions in the up method are run. When the Migration is rolled back, the instructions in the down method are run.

As you can see in this case, the up method creates the table and the default fields as well as the email and passwords fields that we specified from the command line. In the down method, the Migration will simply drop the table from the database.

If you run the migrate command now from the Terminal, Laravel will create the users table for you:

php artisan migrate

Adding a column with a Migration

If you want to add a column to a table using a Migration, you simply have to run a slightly different command to generate the right instructions.

For example, we also want our users to have a username.

To add this column, you would simply run this command in Terminal:

$ php artisan generate:migration add_username_to_users_table --fields="username:string"

Notice how it is add instead of create? This will create the following Migration file.

class AddUsernameToUsersTable extends Migration {

  /**
   * Run the migrations.
   *
   * @return void
   */
  public function up()
  {
    Schema::table('users', function(Blueprint $table) {
      $table->string('username');
    });
  }

  /**
   * Reverse the migrations.
   *
   * @return void
   */
   public function down()
   {
     Schema::table('users', function(Blueprint $table) {
       $table->dropColumn('username');
   });
 }
}

Again, run the migrate command from Terminal to add the username column to the users table.

$ php artisan migrate

Read more about Laravel Migrations

See, how easy was that? Now that you have simple version control for your database, other developers can easily get started working on your project and rolling out changes to the server will be a breeze.

To read more about Laravel Migrations, take a look at the following articles as well as as the Laravel 4 documentation.

• Code Happy – Migrations
• Managing Databases with Migrations

This tutorial is the second in a series of posts showing you how to build an entire web application from scratch. All of the tutorials will be free to web and you see all of the code up on GitHub.

Last week I covered getting started with Laravel 4.

Follow us on Twitter, Facebook or Google Plus to make sure you never miss a post!

Laravel 4 Migrations was written by Philip Brown on Culttt - Articles on business, technology and the Internet

Laravel 4 builds upon the hugely successful Laravel 3 framework, but has taken some dramatic steps forward since the last release. Laravel 4 is now a much more testable framework, whilst still maintaining it’s clean and clear syntax as well as adding a wide array of new components and features.

Laravel 4 leverages Composer to manage updates and to decouple the framework into individual components. You are now much more free to mix and match components from the PHP community. Laravel 4 itself uses some of the most popular components from the Symfony framework, amongst others, so that it does not have to reinvent the wheel.

All of these reasons make Laravel 4 the perfect choice of PHP framework for your next project.

Laravel 4 has not been officially released yet, although the final version release is imminent. However, you can still get started with the framework today.

In this tutorial I’m going to show you everything you need to get started with Laravel 4.

This is actually the second time that I have written this tutorial. The first time I was just explaining the process for setting up Laravel 4 that loosely followed the documentation. However, after reading this great tutorial by Chris Fidao, I decided to rewrite my guide but follow the slightly different method provided by Aaron Kuzemchak here. So kudos to those two, you learn something new everyday. The majority of this post will be standing on the shoulder of giants, but hopefully I can expand on some of the nuances in getting started with Laravel 4.

Requirements

Laravel 4 pretty much needs no configuration out of the box. However, there are a couple of requirements you will need on your local machine.

Firstly you will need to install Composer. Composer is a handy package manager for PHP that allows you to update and manage the different components of your project. If you haven’t already got Composer set up, take a look at my tutorial, What is PHP composer?.

You will also need to be running PHP >= 5.3.7 and you need the MCrypt PHP Extension to be installed. I will be using PHP 5.4+. I’m using OS X, and so the rest of this tutorial will reference that operating system. I’ll assume that you are already have your environment set up, because it’s outside the scope of this tutorial.

And finally, you will of course need to have Git installed. If you are new to Git, take a look at my overview, Why you need to start using Git today.

Installing Laravel 4

So the first thing we need to do is to clone the Laravel repository from GitHub. As I mentioned at the top of this post, Laravel 4 hasn’t officially been released yet, but we can start using it today by cloning the develop branch.

$ git clone -o laravel -b develop https://github.com/laravel/laravel.git cribbb

Here I’m using the git clone command to get the latest copy of the framework and save it into the directory named cribbb.

-o laravel means the remote branch will be named laravel instead of the default of origin. This is so we can pull in changes to the framework, but still maintain our own origin.

-b develop means we want the develop branch.

To read more about the git clone command, take a look at the documentation.

Once the Laravel repo has been cloned, move into the project directory:

cd cribbb

Next we need to create our own Master branch so this project starts at the beginning of it’s own timeline. To do this, run the following command.

git checkout --orphan master

This basically creates a new branch with a new timeline with no parent branches and calls it Master.

Again, to read more about this specific command and the options, take a look at the in-depth documentation.

Now we need to commit the changes.

Run the following command to see all the new framework files that have not been committed to our repo yet:

git status

Next, commit all the files with a message:

git commit -m "Initial commit"

Now when you want to update Laravel, you can run:

git fetch laravel

git fetch will download updates from the laraval repository (documentation).

And to merge updates, you would run the following command:

git merge --squash -m "Upgrade Laravel" laravel/develop

This will merge the updates as one commit (documentation).

Now you can run composer update to update any composer registered libraries (note I’m running composer.phar globally from my usr/local/bin directory).

composer update

Now that you have this set up, whenever a component is updated you can just run composer update to get the latest updates without having to mess with updating files within directories.

And finally, set your own origin by running the following command with your own git repo url.

git remote add origin git@github.com:philipbrown/cribbb.git

Configuring Laravel

The only configuration option that we need to set up now is to create the encryption key that is used within the framework. To do this, all we need to do is to run:

php artisan key:generate

Running Laravel

Now that we have Laravel installed, it’s all ready to run. If you are using PHP 5.4, you can run the following command from Terminal to quickly start up the server without having to create a new Virtual Host.

$ php artisan serve

Now if you visit http://localhost:8000 in your browser you should see the Hello World! front page.

If you aren’t using PHP 5.4, you will just need to create a new VirtualHost and point it to the /public directory of your project.

Now is a good time to commit your work to Git.

$ git add -A
$ commit -m "Yay"

Congratulations! You have just set up Laravel 4!

About this series

This is the first of a huge series on creating a web application from scratch. Over the course of many future weeks, I’m going to show you how to create a web application and everything that goes into it.

The application I’m going to create is going to be called Cribbb. I haven’t fully decided what it’s going to be yet, so I’m just letting the project find it’s own direction.

I’m going to be (obviously) using Laravel for all of the server side stuff and we’ll create a RESTful API.

I’m going to use Ember.js for all of the client side stuff and we’ll be using Sass and a lot more cool new front end stuff that you might not have used in a project before.

Hopefully this will be a good guide for going from an idea to a fully working web application as well as practical tutorials in getting started with some of the latest technology for building online products.

And all these tutorials will be free to web and all of the code will be open sourced on GitHub.

So if you have an idea for an online application, but you don’t know where to get started, follow along with this tutorial series as I show you everything you will need to do to create a modern web application.

Remember to follow Culttt on Twitter, Facebook or Google Plus to make sure you never miss a tutorial!

See you next Monday!

Getting started with Laravel 4 was written by Philip Brown on Culttt - Articles on business, technology and the Internet

In this post I hope to explain exactly what REST means, how you can use it to get data from web services and how you can build your web applications to take advantage of RESTful architecture.

What is REST?

Representational State Transfer (REST) is a type of distributed software architecture that is predominately used on the Internet. REST basically controls how data is sent to and from servers and clients and acts as a set of rules that govern this type of data transfer.

REST follows many of the same conventions as Hypertext Transfer Protocol (HTTP), making it easy to pick up and understand.

When using REST, you will usually want to do one of the following four actions:

• Create (POST)
• Retrieve (GET)
• Update (PUT)
• Delete (DELETE)

POST, GET, PUT and DELETE are HTTP request methods. By making each of the methods represented by a verb, the methods are easy to understand and remember.

This all might seem complicated, but you’ve already been using all of these methods whilst browsing the web. The two most common and visible HTTP methods are POST and GET.

When you submit data through a form on a website, you are making a POST request. A POST request is simply a message to the server that has the submitted data within the body.

It’s easy to spot a GET request because it is often visible in the URL of the website. For example, http://www.youtube.com/watch?v=9bZkp7q19f0 is using a GET request. In this example, your browser is using a GET request to get the video that is represented by 9bZkp7q19f0.

REST URIs

An important part of RESTful architecture is the URIs that are used to transfer data. REST URIs are structured to ensure that they are intuitively understandable and obvious as to their purpose.

For example, to get all the users of a particular service, the REST URI would usually look like this:

domain.com/users

This would return all of the users of the system.

To get the details of a particular user, the REST URI could be:

domain.com/users/1

As you can see, the purpose of these URIs is extremely obvious and follows in the intuitive nature of RESTful architecture.

JSON, XML or both

When you make a REST request, you are returned a representation of the data from the server. The data you are returned is not the actual database, but rather data in a format such as XML, JSON or both.

XML (Extensible Markup Language) is a markup language that is used to store and transfer data. JSON (Javascript Object Notation), despite it’s name, is a language agnostic method for serialising and transferring data.

When transferring data you can use either XML or JSON. Often web services will offer both formats. There are many differences between the two formats and so it’s hard to say whether one is better than the other. XML is a markup language and is used for transferring different types with great flexibility. JSON is generally lighter than XML and so the same amount of data can be transferred with less bandwidth. JSON also fits nicely with Javascript heavy web applications.

The choice between XML or JSON really comes down to your application. Whilst JSON is perfect for lightweight data transfer in web applications, it does have restrictions and constraints that XML does not.

REST Vs SOAP

SOAP (Simple Object Access Protocol) is a protocol for transferring data across networks. SOAP relies on XML and is generally considered much more complicated than REST.

REST is simpler than SOAP because it is based on GET, POST, PUT and DELETE. SOAP on the other hand has it’s own methods for accomplishing the same things. This means you inherently already know how to use REST, whereas SOAP requires a level of learning.

REST is also generally considered better than SOAP because it allows for JSON. As I mentioned earlier, this is particularly important for consumer web services that rely on Javascript heavy web applications and require a much simpler and lighter method for data transfer.

SOAP is older than REST and comes burdened with specifications for it’s use. REST has no specifications and so once again, it makes it easier to use.

SOAP does have some specific advantages over REST. For example, REST only allows for SSL as a method for security, whereas SOAP has security features like WS-Security, although you wouldn’t need it for the average application.

REST is seen as the future of web applications because it is hard to find a case where SOAP is actually a better choice. REST is easier, simpler and has become the chosen method for companies like Google Facebook and Twitter. REST forms an integral part of Ruby on Rails and allows for easy integration with Ajax heavy asynchronous applications.

Conclusion

So to conclude, REST is a type of data transfer that is built upon the architecture of the HTTP protocol. It allows you to easily send and retrieve data between two different services using XML or JSON.

When structuring your web applications, it’s usually good practice to build them using RESTful architecture. This means that collections and resources are easily recognised and can form the basis of building a RESTful API.

When you build an application that requires a Javascript heavy front-end, or integration with a smartphone application, using a RESTful architecture becomes a necessity because it allows you to transfer data from the API to the client. It’s often good practice to plan out your RESTful collections and resources at the very outset.

So the next time you start a web application project, think about how you can make it more RESTful. It will probably not only make your application’s architecture better, but it will also allow you to easily build an API in the future to integrate with other services or applications.

What are RESTful Web Services? was written by Philip Brown on Culttt - Articles on business, technology and the Internet

Using Git for deployment is far superior than FTP in just about every way. In this post I will show you why you should only ever deploy with Git, and how easy it is to set it up.

Why you should use Git?

I’ve already covered why you should use Git in the past, so I will keep this to a brief summary.

Git is a version control system that sits discretely in the background of your project and monitors any changes you make. After you make a change to your code you can commit your changes to Git which makes a new entry in your project’s timeline. This gives you the ability to go back in time and resurrect your code as it was at a certain point in time.

Git is also invaluable when you are working as part of a team of developers or when you are working on a project that has many concurrent development features or versions.

One of the big advantages of using Git is when it comes to deployment. As you probably already know, using FTP for deployment is not very good. FTP requires you to drag and drop files into their correct folders on the server. This means if you need to update a website that has files that are changed in many different folders, it becomes quite difficult. You also face the risk that an unsuspecting user will load a page that breaks because you haven’t finished uploading all of the new files.

Git allows you to manage deployment from the command line. This means you can push a new update and all of the files that are changed are instantly updated at the same time.

It also means that should you push a new update that critically breaks your website, it is really easy to rollback to the previous version. This would be almost impossible using regular old FTP.

So hopefully you can see the many advantages of Git when it comes to deployment. Again, Git will improve your workflow in a number of different areas which you can read more about.

How does Git deployment work with WordPress

There are many different ways you can handle Git deployment using WordPress. Personally, I only use Git for theme deployment, rather than having it manage my entire WordPress installation. This is because I don’t trust open source plugins enough to compromise my deployment. For example say a plugin makes a change to a file on the live server. The next time I push a deployment my files will overwrite this change.

If you do want Git to manage your entire installation, that’s fine. This is a good set up because you can update plugins locally to ensure nothing breaks before it ever hits the live server.

So the overview of how my Git deployment works is:

1. Local repository

Firstly I have my WordPress installation set up locally so I can develop themes and make changes without affecting the live site. Making changes to a live site is a really bad habit that you need to get out of. I have my Git repository set up in /wp-content/themes/my-theme so only the changes to my theme get managed.

2. Git repository on the server

Next I have a bare repository set up on my server. I like to keep all my repositories under /var/git, but you can keep them wherever you want really.

3. Live site files

And finally, I have my live site WordPress installation under /var/www/path-to-live-site as you typically would with any Linux set up.

So the workflow of making changes is:

Local changes
Firstly we make local changes and commit them to Git

Push to the server
Next we push the changes to the Git repository on the server

Automatically update
When new commits are added to the Git repository, it will automatically update the live theme.

It’s that simple. Easy integration with Git and no more FTP.

Let’s set everything up.

Setting up Git and WordPress

So as I’ve outlined above, there are three main stages to setting up Git to work with WordPress:

Local repository

So the first thing to do locally is simply create a new Git repository. I’m going to assume that you already have Git set up on your machine.

To create a new repository, go to the root of your theme and run:

$ cd wp-content/theme/my-theme
$ git init

This will create a new repository.

Next we need to add all the current files to the repository.

// Shows all unstaged files
$ git status

// Adds all files to the current commit
$ git add -A

// Commits the files with a message
$ git commit -m "Add all the things"

Now if you run git status again, there should be nothing left to commit.

Server repository

Next we need to create the server repository. SSH into your server and into the directory where you want to store your Git repositories.

All we have to do at this stage is to create a bare repository. Run the following command in your directory.

$ git init --bare

A bare repository is essentially the same as the local repository you just made but it doesn’t have a working tree. You should use bare repositories to push and pull from on a centralised server because it doesn’t have the complications of a working tree.

Now that we have a repository to push to on the server, we can add an origin to our local repository.

Go back to your local repository and run the following command, substituting your SSH login, server IP and path to the bare git repository you just made:

$ git remote add origin name@123.456.789:path/to/your/git

You should be required to enter your server password.

Origin is simply the main centralised repository. Even though all of your work originated from your local machine, the bare repository is still called the origin. This means that should you ever want to allow access to another developer, all they have to do is pull from the origin.

Next you can run the following command to push your code from your local machine to the server:

$ git push origin master

This is simply saying, push the master branch of the current repository to the origin.

Now if you have a look at the git log of the server’s repository, you should see that your code has been pushed up. Because this is a bare repository without a working tree, your code won’t actually be in the repository.

Automatic update

If you look at your live installation directory, you will notice nothing has changed. In order to automatically update the live files we need to set up a post update hook. This is simply a job that will be run whenever the git repository is updated.

Go into your bare repository, then into the hooks directory.

$ cd hooks

If you list all of the files in this directory you will see a set of sample files that you can use to create your hook.

$ ls -l

To create a post-update hook, simply create a new file and copy the following:

// Create a new file
$ sudo vim post-update

// Copy this text
#!/bin/sh
export GIT_WORK_TREE=/path/to/you/live/files
git checkout -f

This will checkout your files into the directory your have specified every time the repository is updated.

Now if you go back to your local code, make a change, commit the change and push it to the origin you will see your code magically update. You can now deploy changes to your live site without ever having to touch FTP again.

Conclusion

And there you have it, simple Git deployment using WordPress. There are many ways you extend this. For example, you could deploy to a development version or staging version depending on which branch that you push to the origin. This would allow you to test your changes on the server before you deploy the code to the live site.

Hopefully that was a nice and easy introduction to using Git with WordPress. You can of course use the same technique for deployment of any website. I promise you, once you get away from using FTP, you will never look back.

How to deploy WordPress themes with Git was written by Philip Brown on Culttt - Articles on business, technology and the Internet

In Object Orientated Programming, it is inevitable that one object will need to use an instance of another. This is likely going to be happening in places all over your project. Say for example you are using a MySQL database. When you are making calls to the database, you will be using an instance of the database object. But what happens if you need to switch databases to use PostgreSQL instead? Dependancy Injection is a design pattern that allows you to “decouple” these two components so they remain independent.

A second big advantage to Dependancy Injection is when it comes to testing. Recently I introduced Test Driven Development and then we explored PHPUnit. Dependancy Injection is another important part of writing good, well tested software.

Back to our database example. When you are testing your code, you probably don’t want to have to actually connect to a Database. Connecting to a database during testing can slow the process down and it requires you to maintain test data when really all you need to test are the methods that interact with the database. By using Dependancy Injection, you can replace the database object with a static resource that acts the way you would expect the database to act.

So as you can see, Dependancy Injection allows to keep your components independent. Dependancy Injection sounds like such a complicated idea, but really it’s very simple. Essentially it just breaks down to passing an object it’s dependancies, rather than letting it create them itself.

An example of Dependancy Injection

To show you how Dependancy Injection works in real life, here is an example in code. As usual, these examples are in PHP, but hopefully it should be easy enough to translate into whatever language you are using. Don’t take this code too literally, it’s just an example of passing a dependancy, rather than something you would actually want to use.

What not to do

Imagine we have the following database class:

class Database {
  public function __construct(
    $dsn,
    $user,
    $password
  ){
    // Make a connection to the database
  }
}

And we have a User class that creates a new user:

class User {
  private $name;
  private $age;
  private $website;
  private $db;

  public function __construct(
    $name,
    $age,
    $website
  ){
    $this->name = $name;
    $this->age = $age;
    $this->website = $website;
    // Instantiate database
    $this->db = new Database("
      mysql:host=localhost;dbname=database",
      "username",
      "password"
    );
  }
}

This code is bad for 3 main reasons.

1. Multiple concerns
   A class should only ever have one concern. In our User class, we have to deal with the database when really it has nothing to do with the user.
2. Making changes is difficult
   Imagine if you had to change the database type or the username or password in every place where you are using this database connection. As you can probably tell, having your classes too closely coupled like this will make it a nightmare to maintain the codebase in the future.
3. Unit testing is difficult
   Unit testing is also much more difficult because now we have to deal with the database. As I mentioned above, during testing, you only want to be testing one specific thing. With the Database class being created in the User class, it means we can’t switch it out for testing purposes.

The correct way to use Dependancy Injection

Hopefully that example above shows the pain of not using Dependancy Injection.

To refactor this example to use Dependancy Injection, we simply have to pass the database object to the User class constructor:

class User {
  private $name;
  private $age;
  private $website;
  private $db

  public function __construct(
    $name,
    $age,
    $website,
    Database $database
  ){
    $this->name = $name;
    $this->age = $age;
    $this->website = $website;
    $this->db = $database;
  }
}

Now that we are passing an instance of the database to the User class on construction we have solved the three problems that we had before.

1. Single concern
   The User class is now only concerned with the User as it no longer needs to care about the database.
2. No more repetition
   Now that we have cut out all the duplicate code it is now much easier to make a change to the database parameters because we only have to do it once. The User class never needs to care about changes made to the database.
3. Easier to test
   Now that the User class is just given an instance of the database it makes this much easier to test. Now we can just pass an object that provides the same api as the database, but without having to actually make a connection or return real results.

Conclusion

Whilst Dependancy Injection can seem like a difficult term to get your head around, it is really very simple. Dependancy Injection is basically just providing an object with the things it needs, rather than allowing it to create them itself. So if an object requires access to the database, instead of allowing the object to create an instance of the database class, we can provide an instance instead.

Dependancy Injection is really very important when it comes to testing. When you provide an object with it’s dependancies, it makes it very easy to mock them. If you allow an object to create it’s own dependancies, you now need to deal with them during your tests as the object now has multiple concerns.

To find out more about Dependancy Injection, have a read of this article by Fabien Pontencier and this article by Martin Fowler.

What is Dependancy Injection? was written by Philip Brown on Culttt - Articles on business, technology and the Internet

In this post I will be explaining Lambdas and Closures, give you some example code to show their usage and give you a real life example of them in action to show you their prevalence in modern PHP.

What is a Lambda?

A Lambda is an anonymous function that is can be assigned to a variable or passed to another function as an argument. If you are familiar with other programming languages like Javascript or Ruby, you will be very familiar with anonymous functions.

Anonymous functions

An anonymous function is simply a function with no name.

For example, to create a regular function, you might write something like this:

// Regular function
function greeting () {
	return "Hello world";
}

You can then simply call this function like this:

echo greeting();
// Returns "Hello world"

An anonymous function has no name so you would define it like this:

// Anonymous function
function () {
	return "Hello world";
}

Using Lambdas

Because the function has no name, you can’t call it like a regular function. Instead you must either assign it to a variable or pass it to another function as an argument.

// Anonymous function
// assigned to variable
$greeting = function () {
  return "Hello world";
}

// Call function
echo $greeting();
// Returns "Hello world"

To so use the anonymous function, we assign it to a variable and then call that variable as a function.

You could also pass the function to another function, like this:

// Pass Lambda to function
function shout ($message){
	$message();
}

// Call function
shout(function(){
	return "Hello world";
});

Why would you want to use a Lambda?

Lambdas are useful because they are throw away functions that you can use once. Often, you will need a function to do a job, but it doesn’t make sense to have it within the global scope or to even make it available as part of your code. Instead of having a function used once and then left lying around, you can use a Lambda instead.

Of course, you have been able to use the create_function function in PHP for a while now. This basically does the same job.

// Use create_function
$greeting = create_function(
	echo "Hello world";
);

// Call function
$greeting();

What is a Closure?

A Closure is essentially the same as a Lambda apart from it can access variables outside the scope that it was created.

For example:

// Create a user
$user = "Philip";

// Create a Closure
$greeting = function() use ($user) {
  echo "Hello $user";
};

// Greet the user
$greeting(); // Returns "Hello Philip"

As you can see above, the Closure is able to access the $user variable. because it was declared in the use clause of the Closure function definition.

If you were to alter the $user variable within the Closure, it would not effect the original variable. To update the original variable, we can append an ampersand. An ampersand before a variable means this is a reference and so the original variable is also updated.

For example:

// Set counter
$i = 0;
// Increase counter within the scope
// of the function
$closure = function () use ($i){ $i++; };
// Run the function
$closure();
// The global count hasn't changed
echo $i; // Returns 0

// Reset count
$i = 0;
// Increase counter within the scope
// of the function but pass it as a reference
$closure = function () use (&$i){ $i++; };
// Run the function
$closure();
// The global count has increased
echo $i; // Returns 1

Closures are also useful when using PHP functions that accept a callback function like array_map, array_filter, array_reduce or array_walk.

The array_walk function takes an array and runs it through the callback function.

// An array of names
$users = array("John", "Jane", "Sally", "Philip");

// Pass the array to array_walk
array_walk($users, function ($name) {
	echo "Hello $name<br>";
});
// Returns
// -> Hello John
// -> Hello Jane
// -> ..

Again, you can access variables outside the scope of the Closure by using the use clause:

// Set a multiplier
$multiplier = 3;

// Create a list of numbers
$numbers = (1,2,3,4);

// Use array_walk to iterate
// through the list and multiply
array_walk($numbers, function($number) use($multiplier){
	echo $number * $multiplier;
});

In the example above, it probably wouldn’t make sense to create a function to just multiply two numbers together. If you were to create function to do a job like this, then come back to the code a while later you will probably be thinking why did you bother create a globally accessible function only to be used once? By using a Closure as the callback, we can use the function once and then forget about it.

Real life usage

So we’ve established that Lambdas and Closures are anonymous functions that can be used as throw away bits of functionality that don’t pollute the global namespace and are good to use as part of a callback.

A popular example of the use of these types of functions is in routing requests within modern frameworks. Laravel for example, allows you to do the following:

Route::get('user/(:any)', function($name){
  return "Hello " . $name;
});

The code above simply matches a URL like /user/philip and returns a greeting.

This is a very basic example, but it highlights how a Closure can be utilised in a very useful situation.

Conclusion

So hopefully that was a good explanation of Lambdas and Closures.

Lambdas and Closures seem like two very deep Computer Science terms if you are a newbie programmer. However, it’s actually not that complicated at all. Both Lambdas and Closures are simply anonymous functions that are useful for one offs or where it doesn’t make sense to define a function.

Lambdas and Closures are fairly new to PHP and they don’t follow exactly the same usage as in other languages. If you are at all familiar with Javascript, you will see anonymous functions used a lot. In particular, you will see a lot of good examples in jQuery. Once you can recognise the pattern, it makes reading code a lot easier because you not only understand what is going on, but also understand why it was written like that in the first place and what the developer was trying to achieve through her decisions.

What are PHP Lambdas and Closures? was written by Philip Brown on Culttt - Articles on business, technology and the Internet

PHPUnit is the de-factor standard for Unit testing PHP. PHPUnit is essentially a framework for writing tests and the necessary tools that you will need to run tests and analyse the results.

In this post I will show you how to get up and running with PHPUnit and how it should fit into your workflow.

Install PHPUnit via Composer

The first thing we need to do is to install PHPUnit through Composer. By doing this, we can set PHPUnit as a dependancy on our project which can managed easily going forward.

If you are unfamiliar with Composer, take a look at What is PHP Composer?

So firstly, create a new folder and a new composer.json file. In your Composer file, write the following:

{
  "require": {
    "phpunit/phpunit": "3.7.*"
  }
}

Next, open Terminal and run:

$ composer install

Composer should now automatically download PHPUnit into your project and set up all the required files. If everything has worked correctly you should now have a vendor folder that contains PHPUnit amongst other things.

Setting up a test

Now that you have PHPUnit set up, we can start writing some tests.

When writing tests, you should keep them all together in the same directory. So first, move back to the root of your project and create a new directory called tests.

For this tutorial, I’m going to be creating a Car class. So within your tests directory, create a file called CarTest.php. It’s common practice to name your test classes after the real class but with “Test” appended. You don’t have to do this, but it will make things a lot easier when you come back to it or another developer has to continue your work.

In the CarTest.php file, create a new Class that extends PHPUnit.

<?php
class CarTest extends PHPUnit_Framework_TestCase{

}

Writing the first test

Next we will write our first test. The first test I want to write is to test that the name of the car is getting set correctly when the Class is instantiated. To do that, we can write a test like this.

public function testName(){

}

First we create a new test method. You should always start your test method names with “test” and then describe your test using camel case.

Next we can create a new instance of the Car class

public function testName(){
  // Create new Car and pass in a name
  $car = new Car("Murcielago");
}

Watching a test fail

Hopefully you will have noticed that we haven’t actually created the Car class so it would be impossible to create a new instance of it. So now that we have written our test, we can run PHPUnit and watch it fail.

Open up Terminal again and run the following command:

vendor/bin/phpunit tests/CarTest.php 

This simply runs PHPUnit on our CarTest.php file. You can alias the PHPUnit command so you don’t have to type out the full path name.

Once you have run that test, you should have got the following error:

PHP Fatal error:  Class 'Car' not found

As you probably guessed, the test failed because there is no such thing as the Car class.

Writing just enough code

To make the test pass, we need to actually create a Car class. So back in the root of your project, create a new file called Car.php and write the following:

<?php
class Car {

}

Next, in your CarTest.php file, add the following line to include the Car class.

include 'Car.php';

Next run the same test again. You can just hit the up arrow key in Terminal to run recently run commands again.

If you have done everything right, the test should pass. Congratulations, you’ve just taken your first big step in Test Driven Development!

Let’s quickly review what we have done so far.
First, we wrote the test for our required functionality.
Second, we watched the test fail.
Third, we wrote just enough code to make the test pass.

Hopefully if Test Driven Development seemed a bit foreign to you at the start of the this tutorial than the process that we’ve just stepped through should clear it up. Essentially, Test Driven Development is just breaking down the problem, creating a test to ensure what we are hoping to achieve will work, watching it fail and then writing the code to make it pass. In this way we can be sure that what we are writing is going to be working exactly as we expected it to do. In the future, if we ever write code that breaks this test, we will be alerted to it by running PHPUnit.

Assertions

If you flick back to your Terminal and read the output, you should notice following line:

OK (1 test, 0 assertions)

Our test passed, but we didn’t actually test to see if the name was getting set correctly.

We can now write the test to assert if the name is getting set correctly or not.

Go back to your CarTest.php file and add the following to the testName() method:

public function testName(){
  // Create new Car and pass in a name
  $car = new Car("Murcielago");
  // Get the car name
  $result = $car->name();
  // Assert that the name has been set correctly
  $this->assertEquals("Murcielago", $result);
}

Now run the test again in Terminal. You should get the following error.

PHP Fatal error:  Call to undefined method Car::name()

Looks like we haven’t created the name method yet. Open up Car.php and create the name method.

public function name(){
}

Now run the test again. You should get the following error.

Failed asserting that null matches expected 'Murcielago'.
Tests: 1, Assertions: 1, Failures: 1.

Perfect! Our test failed for exactly the reason we were looking for. The name of the car is not being set. Next we can write the code to make the pass test.

First declare the name as a property of the class:

protected $name;

Next add a construct method that set’s the name when the class is instantiated.

public function __construct($name){
  $this->name = $name;
}

Next return the name within the name method.

public function name(){
  return $this->name;    
}

Next run your test again. You should get the following result:

OK (1 test, 1 assertion)

Woohoo, our test passed! So as you can see, first we wrote our test and let it fail, then we wrote just enough code to make it pass.

Conclusion

This is really just scratching the surface of Test Driven Development with PHPUnit. In the future I will write more in-depth tutorials on how you should write tests for each aspect of your application.

Hopefully for now, you should have a strong grasp of Test Driven Development, you’ve seen how it works in real life and I’ve shown you how to get started.

Now go write some tests.

Getting started with PHPUnit was written by Philip Brown on Culttt - Articles on business, technology and the Internet

In the fast paced world of software development, there will always be bugs in code. When you are deploying to the live server multiple times per day, you increase the likelihood that you have introduced a bug in new code, or you have broken something in the existing architecture.

One of the key components of Continuous Integration is having automated tests run through your code to check that everything is working as it should.

Setting up tests for code that you have already written can seem laborious and time consuming. Test Driven Development (TDD) is a software development process that promotes writing tests from the outset.

In this post I will introduce the concept of Test Driven Development, how it works and why you should consider changing your workflow.

Whilst there is far more to Continuous Integration than a testing framework, it is an important first step if you want to move your software into a more stable and fast moving architecture.

What is Test Driven Development?

Test Driven Development (TDD) is the process of writing tests during the development of software. Typically, TDD will break each task of the development into individual units. A test is then written which will ensure that the unit behaves as expected.

Over the course of developing the software, the developer will build up a framework of tests for each individual component of the architecture. These automated tests can be run periodically to ensure that each individual component is still behaving as expected.

Why should I use Test Driven Development?

Whilst Test Driven Development makes the actual writing of code slower, there are a number of advantages to taking this approach.

Firstly, you ensure that your code is working exactly how you mean it to. Often code will seem to work correctly, when in fact there is some underlying reason why it will fail under a certain condition. Test Driven Development looks to remove this problem by ensuring that each individual component is working correctly.

Secondly, testing an application through a browser can be extremely time consuming and it’s pretty easy to overlook or miss a serious bug. Test Driven Development enables you to set up test cases to test each element of validation, database requesting and all of your business logic so that each individual component gets tested.

And thirdly, when you come to make changes to your code in the future you could unwittingly make a change that breaks another mission critical part of your application. When making changes, you are only going to be manually testing the areas of the software that you think you will have effected. It’s really easy to forget about some underlying structure once an application becomes complicated. Test Driven Development will highlight exactly where something has broken, and allows you ship your latest release without worrying that you have left something broken.

An excellent analogy for Test Driven Development is, TDD is like brakes on your car. Without breaks on a car, you would be forced to drive really slowly. However, because breaks allow you to control when you stop, it allows you to drive much more freely. Test Driven Development removes all of the stress of shipping broken code, and allows you to get on with the job of improving your application.

What is the Test Driven Development cycle?

The Test Driven Development cycle is a bit of a departure from the normal way of writing code so it can take some getting used to.

Write a test

Before you write any actual code, you need to write your test so you can watch it fail. Writing the test first ensures that you can confidently say that you made the test pass for the right reasons.

Watch it fail

At this point it’s pretty obvious it’s going to fail because there is nothing to test! This incremental approach keeps you on the right track of breaking each component down in to it’s smallest unit.

Write the bare minimum code to make it pass

Now you need to write the bare minimum amount of code to make the test pass. It’s important that you only write enough to make the test pass because you will need to write additional tests for any additional code you write.

Refactor

During the process of writing code in Test Driven Development, you will probably need to refactor your code every so often. Writing code that makes tests pass isn’t always as optimum as it could be.

Every so often, loop back and evaluate how you can rewrite something to improve it and keep it DRY. Fortunately you don’t have to worry about breaking any of your code during refactoring because you can just run your tests again.

Terminology

As with just about everything, Test Driven Development introduces terminology that you may be unfamiliar with. It’s difficult to understand something if you don’t understand the terminology and so here is an explanation of some of the common terms that you will come across.

Unit Testing

As covered above, Unit Testing is where you break down you code into small individual components that can be tested independently. By testing each individual component, you ensure that your tests are passing because the unit is behaving correctly and not because it is tied to another unit of code.

Integration Testing

Once you have a number of Units that have all been individual tested, you can put them all together and test them as a group. This is known as Integration Testing. This ensures that all of the individual components are working together correctly.

Validation Testing

Finally Validation Testing is usually the process where your code is given to software testers to ensure that the feature is working as intended. This can often be achieved by doing sanity checks within the browser.

Test Stubs

In complex applications, it’s rare to find components that aren’t tied or coupled to other components in some way. Often the part of the code that you want to test is dependant on some other part of the code.

For example, when you are testing returning results from a database, you will need to test the Model independently from the Database.

A Test Stub acts as a replacement to the dependancy. This allows you to test your code without having to actually make real calls to a database.

Mock Objects

Similar to Test Stubs, Mock Objects act as a replacement for dependant objects when running Unit Tests. Mock Objects are useful when you want to simulate a state of your application that can only be achieved with the presence of certain Objects.

For example, say you had integrated Twitter into your application and you need to simulate interaction with Twitter without having to actually make a connection for each test. Instead, you could create a Mock Object that would simulate the interaction with Twitter and allow you to Unit Test your code without depending on the external service.

Build Server

Deploying from a Build Server is a common approach taken by larger application projects. Essentially a Build Server is just a dedicated server the manages deploying changes to production.

When you have many developers working on a project together, each developer’s environment can slightly differ. Having a Build Server ensures is a last level of defences for catching bugs.

For a more in depth explanation of why Build Servers are important, take a look Daily Builds Are Your Friend by Joel Spolsky.

Conclusion

Test Driven Development can seem like a big departure from your current workflow as you need to introduce a significant amount of extra work just to write code. However, when you come to work on big projects and collaborate with other developers, writing tests starts to become a necessity.

Test Driven Development shouldn’t completely slow down your productivity. Finding the right balance of writing tests and writing code is important to ensuring that you can actually get work done and ship your product.

But it’s hard to argue against being able to quickly test your entire codebase to ensure that everything is working correctly.

What is Test Driven Development? was written by Philip Brown on Culttt - Articles on business, technology and the Internet