Basic ProcessWire website workflow - Part Three

Introduction Following Part 1 and Part 2. In this Post we will look on how to implement the PW modules introduced in Part 1. Let’s recap them: MarkupSimpleNavigation: to generate the main navigation menu AIOM: to concatenate, minify and cache our assets MarkupSEO: the SEO solution for PW MarkupGoogleMap: to embed a Google Map on your pages ProcessSlider: to create image sliders for your pages ProcessHannaCode: to insert any complex HTML, Javascript or PHP output in your ProcessWire content There are a few methods to install PW modules. For each module you can download the corresponding ZIP archive from the modules directory on the PW website. Then you have to extract the content in a folder, named after the module class, in the /site/modules directory. Otherwise you can use the Modules Manager to browse modules directly from your website. However my favourite method is simply to add the module straight...

Read More
Basic ProcessWire website workflow - Part Two

Introduction Following the Part One. In the previous article we have set the foundations, now it’s time to actually code the pages our basic website. Template Inheritance Let’s start by explaining the concept of template inheritance. The Smarty documentation provides a nice explanation of this approach, which allows the developer/designer to compose each page by writing only the necessary code and inheriting or including the common parts that are shared. “Template inheritance is an approach to managing templates that resembles object-oriented programming techniques. Instead of the traditional use of {include …} tags to manage parts of templates, you can inherit the contents of one template to another (like extending a class) and change blocks of content therein (like overriding methods of a class.)” As a general rule, the shared parts of the website should live in different files. If you think about it, coding the header and the footer on...

Read More
Test Laravel filesystem storage with Virtual File System

Introduction Since Laravel 5, the filesystem operations are abstracted thanks to the Flysystem PHP package by Frank de Jonge. This integration provides simple drivers for working with local filesystems, Amazon S3, and other Cloud Storage. The API remains the same for each system therefore is really simple to swap between each storage option. Testing the filesystem is not an easy task. I covered some of the challenges in a previous blog post, but luckily we have a couple of tools at our disposal that can simplify considerably our work. Flysystem Adapters As I said, Laravel uses the Flysystem library to abstract the filesystem. This library makes use of the adapter pattern: “the inconsistencies of the different file systems are leveled out by adapters, which translate requests into calls the file system understands and re-format responses to comply with the interface of the generic file system.” Flysystem provides all different kinds...

Read More
SQLite In-Memory Database for Unit Tests in Laravel

Introduction When testing your code (and this is particularly true for functional tests), even if you mock most of the database iteractions, at some point you need to hit the persistent layer of your application in order to ensure that everything works correctly. In these cases you obviously are not willing to make definitive changes to your development database each time you run a test. Luckily for us Laravel 5 provides two useful methods to solve this problem: Database Transactions Each time you run a test, Laravel will cleverly wrap the database calls in a transaction, so when the test finishes the transaction rolls back, leaving the database in its previous state. Switch to a test database You can set up an alternative database to use when Laravel switches to a test environment. However you still have to make sure that this database remains in the same state between each...

Read More
How to test the File System using vfsSream. An example with CSV files.

Introduction Let’s face it! In some situations, no matter how hard you try to mock everything, you have to unit test the file system in order to ensure that your application works correctly. Testing directly the file system is a pain in the ass due to the many possible things that can go wrong. Remember: unit tests must be performed in isolation, therefore we need to make sure that each test case doesn’t affect the outcome of the others. The old-fashioned way to avoid possible pitfalls relies on the setUp and tearDown methods, to clear the stage between each test: <?php public function setUp() { if (file_exists(dirname(__FILE__) . '/test_folder') === true) { rmdir(dirname(__FILE__) . '/test_folder'); } } public function tearDown() { if (file_exists(dirname(__FILE__) . '/test_folder') === true) { rmdir(dirname(__FILE__) . '/test_folder'); } } ?> However if our test dies before the tearDown method is called the directory will stay in...

Read More
Inspect the response in Laravel PHPUnit tests

The Problem Sometimes, when running integration tests using Laravel and PHPUnit, it’s useful to inspect the response when you can’t figure out why the test is failing. In Laravel 5 and later versions, testing has been highly improved with an API that allows nice and fluent interaction with your application. Inspect the Response Object In Laravel, each Test extends the default abstract TestCase class defined in Illuminate\Foundation\Testing. This class uses the CrawlerTrait to provide iteraction with the application, therefore it contains the $response property, which is an instance of \Illuminate\Http\Response and contains the last response returned by the application. For this reason we can use the getContent() method on the response object to check what the application actually returned. In the following example we are first creating a new user in the database, then we use the chainable API to interact with the application. Finally we use the dd function...

Read More