For this to be possible, the User model must have a $factory array describing its fields too. Notice how you can access the User relation through $post->author. As an example, we can access the $post->author->username, or any other existing user attribute. The FactoryMuff package enables rapid instantiation of consistent objects for the purpose of testing, while respecting and instantiating any needed relationships. In this case, when we create a Post with FactoryMuff::create('Post') the User will also be prepared and made available. To finish, we determine if the string returned by the postedAt() method follows the "day/month/year" format. For such verification, a regular expression is used to test if the pattern \d{2}\/\d{2}\/\d{4} ("2 numbers" + "bar" + "2 numbers" + "bar" + "4 numbers") is found. Alternatively, we could use PHPUnit's assertRegExp matcher. At this point, the app/tests/models/PostTest.php file is as follows: PS: I chose not to write the name of the tests in CamelCase for readability purposes. PSR-1 forgive me, but testRelationWithAuthor is not as readable as I would personally prefer. You're free to use the style that you most prefer, of course. ### Page model Our CMS need a model to represent static pages. This model is implemented as follows: We can observe that the static method, renderMenu(), renders a number of links for all existing pages. This value is saved in the cache key, 'pages_for_menu'. This way, in future calls to renderMenu(), there will be no need to hit the real database. This can provide significant improvements to our application's performance. However, if a Page is saved or deleted (afterSave() and delete() methods), the value of the cache will be cleared, causing the renderMenu() to reflect the new state of database. So, if the name of a page is changed, or if it is deleted, the key 'pages_for_menu' is cleared from the cache. (Cache::forget('pages_for_menu');) NOTE: The method, afterSave(), is available through the Ardent package. Otherwise, it would be necessary to implement the save() method to clean the cache and call parent::save(); ### Page tests In: app/tests/models/PageTest.php, we'll write the following tests: Once again, we have an "optional" test to confirm the relationship. As relationships are the responsibility of Illuminate\Database\Eloquent, which is already covered by Laravel's own tests, we don't need to write another test to confirm that this code works as expected. This is one of the most important tests for the Page model. First, four pages are created in the for loop. Following that, the result of the renderMenu() call is stored in the $result variable. This variable should contain an HTML string, containing links to the existing pages.

The foreach loop checks if the slug (url) of each page is present in \$result. This is enough, since the exact format of the HTML is not relevant to our needs.

Finally, we determine if the cache key, pages_for_menu, has something stored. In other words, did the renderMenu() call actually saved some value to the cache?

This test aims to verify if, when saving a new Page, the cache key 'pages_for_menu' is emptied. The FactoryMuff::create('Page'); eventually triggers the save() method, so that should suffice for the key, 'pages_for_menu', to be cleared.

Similar to the previous test, this one determines if the key 'pages_for_menu' is emptied properly after deleting a Page.

Your PageTest.php should look like so:

### User model

Related to the previously presented models, we now have the User. Here's the code for that model:

This model is absent of tests.

We can observe that, with the exception of relationships (which can be helpful to test), there is not any method implementation here. What about authentication? Well, the use of the Confide package already provides the implementation and tests for this.

The tests for Zizaco\Confide\ConfideUser are located in ConfideUserTest.php.

It's important to determine class responsibilities before writing your tests. Testing the option to "reset the password" of a User would be redundant. This is because the proper responsibility for this test is within Zizaco\Confide\ConfideUser; not in User.

The same is true for data validation tests. As the package, Ardent, handles this responsibility, it wouldn't make much sense to test the functionality again.

In Short: keep your tests clean and organized. Determine the proper responsibility of each class, and test only what is strictly its responsibility.

## Conclusion

The use of an in-memory database is a good practice to execute tests against a database quickly. Thanks to help from some packages, such as Ardent, FactoryMuff and Confide, you can minimize the amount of code in your models, while keeping the tests clean and objective.

In the sequel to this article, we'll review Controller testing. Stay tuned!

Still getting started with Laravel 4, let us teach you the essentials!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.