2015-08-29 Laravel Package Creating a Laravel 5.x Package
In this final part of the series we cover perhaps the most important and often overlooked part of package development. Unit testing ensures greater stability as yourself and others improve and update the package. Without even some basic unit testing it makes it hard to maintain the package as it evolves over time.
We will need to install phpunit
into each of our Laravel install directories. Let's open the composer.json
file in whatever version of Laravel you want to run the tests from.
"require-dev": {
...
"phpunit/phpunit": "4.8.*"
},
The version at the time of this writing was 4.8.1
, but you can just check Packagist phpunit page for the latest version. Once we add this we'll need to do a composer update
.
> composer update phpunit/phpunit
The next step is to create the phpunit.xml
file in the root of our package. We can just use the sample below to start but of course you can put in your own configuration as well.
// packages/websanvoa/demo/phpunit.xml
<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
backupStaticAttributes="false"
colors="true"
convertErrorsToExceptions="true"
convertNoticesToExceptions="true"
convertWarningsToExceptions="true"
processIsolation="false"
stopOnFailure="false"
syntaxCheck="false"
>
<testsuites>
<testsuite name="Package Test Suite">
<directory suffix=".php">./tests/</directory>
</testsuite>
</testsuites>
</phpunit>
We will then also create a tests
directory in the root of our package. In there we will house our test files.
// packages/websanova/demo/tests/DemoTest.php
class DemoTest extends TestCase
{
public function testSomethingIsTrue()
{
$this->assertTrue(true);
}
}
Now we will need to run phpunit
from the packages directory we want to test from.
> cd /path/to/packages/websanova/demo
> ../../../vendor/bin/phpunit
We do it this way so that we can include the phpunit.xml
file for our package which may have it's own specific configuration. This also makes it easier to distribute the package for other developers who may wish to contribute allowing them to use their own workflows.
We didn't get into specific testing concepts as there is a lot of great material on the web for that topic already. The idea was just to get your tests setup with your package.
This concludes the series and pretty much wraps up package development. Hopefully you will now have all the tools you need to build your own packages.