Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Matthew Weier O'Phinney:
Automating PHPUnit with Node
Oct 25, 2016 @ 09:06:40

Matthew Weier O'Phinney has a new post to his site today showing you how you can automate PHPUnit runs while doing local development with the help of a little Node.

I've been trying to automate everything this year. When working on OSS, this is usually as simple as setting up Travis CI; in some cases, even that becomes a little more involved, but remains possible.

But that's continuous integration. What about continuous development? With continuous integration, every time I push to a branch associated with a pull request or on the origin repository, a build is triggered. [...] Ideally, I should also be testing locally. [...] I'd like to automate running these as part of my development process. I want continuous development cycles.

He then walks you through the automation setup he's devised for his own local development, adding a few lines to his Composer configuration for scripts to run when "composer check" is called. This is where Node comes in: he uses Gulp (and a few dependencies) to watch the filesystem for changes. With that setup configured and working, he can then just run "gulp" and a Node process executes and watches for those changes. When an update is discovered, "composer check" is executed and a system notification is fired if an error pops up. He's also created a package you can use to set this all up a bit simpler, only requiring a single command to execute.

tagged: phpunit automation node gulp tutorial watch phpunit unittest

Link: https://mwop.net/blog/2016-10-24-watch-phpunit-with-node.html

SitePoint PHP Blog:
Testing PHP Code with Atoum – an Alternative to PHPUnit
Oct 21, 2016 @ 11:52:28

The SitePoint PHP blog has a tutorial posted introducing you to a more recent addition to the testing tools available to PHP: atoum. The tutorial provides the basics and shows you how to use it in testing your code as an alternative to PHPUnit.

f you’ve been around PHP for more than a little while, you’ve no doubt started to test your code. And if you ask anyone in the PHP space what to use for writing unit tests, likely the first answer that they’ll give you is PHPUnit.

It’s the de facto standard in the PHP community, and with good reason. But it’s not the only choice. Whilst it does command the lion’s share, other choices abound, one of which I’m going to take you through in this tutorial; it’s called atoum.

They briefly introduce the tool (a "simple, modern, and intuitive unit testing framework for PHP") and help you get it installed. They also recommend installing the "atoum/stubs" package as well, making it easier to do autocomplete in most IDEs. From there the tutorial helps you configure your atoum installation to allow for code coverage reports to be generated. With things configured nicely, the next step is creating a first test evaluating a simple method that either works correctly or throws an exception. Code is included showing how to use the testing to set up expectations and evaluate the results of method execution. Finally they show the command to execute the test(s) and what the resulting code coverage reports look like.

tagged: testing unittest atoum introduction tutorial alternative

Link: https://www.sitepoint.com/testing-php-code-with-atoum-an-alternative-to-phpunit/

Adam Wathan:
Replacing Mocks with Spies
Oct 13, 2016 @ 10:25:14

In this post to his site Adam Wathan shares a unit testing tip that can help you with more correct verification in your testing - replacing mocks with spies.

Mock objects are useful when verifying that a method was called is more important than verifying the outcome of calling that method.

[...] Mocks are a great tool, but it’s always bugged me that they force you to set expectations in advance instead of making assertions at the end like you would in a traditional test.

He gives a Laravel-based example of using Mockery to set an "expects" call on a method to ensure it's correctly called. He points out, however, that this method is more useful for checking the result of the method call and not really the fact that it was called (a slight but interesting difference). He then gives an example of testing the PHP function strrev and the phases you would go through in the testing process. He suggests that, in the creation of the mock object, you're mixing up the "setup" phase with the "assertion" phase and making them dependencies. He shows how, with a switch over to using spies instead, including the code updates for Mockery that change the mock object creation and split out the assertion from the creation.

tagged: mock spy unittest mockery assertion setup

Link: https://adamwathan.me/2016/10/12/replacing-mocks-with-spies/

Jani Hartikainen:
5 step method to make test-driven development and unit testing easy
Oct 11, 2016 @ 10:23:08

While his examples may be in Javascript, Jani Hartikainen has posted a guide that can help any developer get started with TDD - Test Driven Development - in their new or legacy applications.

What’s the hardest thing in test-driven development or unit testing in general? Writing tests! The syntax or the tools aren’t the problem – you can learn those enough to get started in 15 minutes. The problem is how to take some vague idea in your head about what you want to do, and turn it into something that verifies some function works… before you even wrote the damn thing!

People tell you to use TDD. But how can you possibly write a test for something that doesn’t exist? I don’t even know what the function is going to do yet – or if I actually want two functions instead of one – and instead you want me to think of a test for it? Are you crazy?

How do all those people who tell you to use TDD do it? That’s the thing – test-driven development requires thinking of your code in a different way. And nobody ever tells you how to do that. Until now.

He then breaks down the process of how to turn a "vague idea" into something that can be effectively tested, noting that this change in thought process can sometimes be difficult. He then breaks it down into a set of five steps:

  • Step 1: Decide the inputs and outputs
  • Step 2: Choose function signature
  • Step 3: Decide on one tiny aspect of the functionality
  • Step 4: Implement test
  • Step 5: Implement code

While the above may seem familiar to anyone that's read about TDD before, it's interesting to see how he explains each item with an emphasis on behavior not just the code required. He ends the post with a few more smaller suggestions to help you get on the road to TDD with the same emphasis on behavior rather than functionality.

tagged: tdd testdriven development steps easy unittest behavior

Link: http://codeutopia.net/blog/2016/10/10/5-step-method-to-make-test-driven-development-and-unit-testing-easy/

Jani Hartikainen:
How many tests is too many?
Sep 13, 2016 @ 09:21:21

While not specific to PHP Jani Hartikainen asks an interesting question in his latest post - how many tests are too many?. He gives an example of the number of tests in a widely used open source project and how, sometimes, more tests doesn't mean better code.

Some time ago I stumbled upon some crazy stuff… Specifically, I found out that SQLite has 787 times more tests than they have actual code! It’s no joke, it’s documented right on their website. While they have about 116 300 lines of source code, they have 91 577 300 lines of test code.

That sounds completely insane. [...] I bet you’ve sometimes wondered what is the right amount of tests to write. In some cases, it’s easy to end up with more tests than code. [...] When thinking of how many tests is enough, we need to think of what the goals are – both for the tests and our actual project.

He focuses in on this last idea, talking more about the SQLite project and its test suite. He then helps answer the main question - how do you know how many tests are enough? Should you "bend over backwards" to make tests for every possible scenario just because you can? He suggests a few things that can help the situation including refactoring where testing is difficult and writing regression tests for bugs fixed.

tagged: testing code opinion toomany unittest sqlite project

Link: http://codeutopia.net/blog/2016/09/10/how-many-tests-is-too-many/

Joe Ferguson:
Solidify Fragile Tests
Sep 05, 2016 @ 11:43:27

In this post to his site Joe Ferguson gives some advice on solidifying tests in your system that are a bit more fragile. Every test suite of any larger size has these kinds of tests - ones that usually pass but sometimes fail (and then pass just fine on the next run).

On my first week at the new job I was tasked to fix some tests that were logging data. While the fix was simple enough, by using `PsrLogNullLogger as Logger` instead of `MonologLogger` in the test, during the process I ran into another test that appeared quite fragile.

He gives an example of a fragile test, one based on a method that returns a "food" value, that would potentially fail if the data returned is not in the right order. He found the issue was with the use of the assertArraySubset check and how, thankfully, the fix was as easy as changing the assertion (and using an array_diff to help with the check).

tagged: solidify fragile tests unittest check assertion update

Link: https://www.joeferguson.me/solidify-fragile-tests/

Testing in Docker (Using Different PHP Versions)
Aug 12, 2016 @ 12:23:58

On the ShippingDocker.com site there's a video (and matching tutorial) posted showing you how to use Docker to test with multiple PHP versions with relatively little difficulty. In this case they're not testing the frontend of the application, they're running its unit tests.

[This is a] quick video on running PHP unit tests against different versions of PHP using Docker. [We'll] cover unit testing with PHP.

They start with an example of using the pywatch tool to do the testing without Docker, automatically executing the tests when something changes. This has the limitation of only being able to use your current, local version of PHP. They then shift over to the Docker side of things and show how to run the same pywatch command inside a container of your choosing, tagging it with the PHP version and making it easy to switch between them in the future.

tagged: docker version unittest different example video screencast tutorial

Link: https://shippingdocker.com/blog/docker-testing/

Adam Wathan:
Stubbing Eloquent Relations for Faster Tests
Aug 08, 2016 @ 11:52:53

Adam Wathan has a recent post to his site showing you how to stub out your Eloquent relations in a Laravel application for use in your testing (rather than hitting the database directly).

When you’re trying to test methods on an Eloquent model, you often need to hit the database to really test your code.

But sometimes the functionality you’re testing doesn’t really depend on database features. Is there any way to test that stuff without hitting the database?

He starts with a look at the more traditional method, using the models normally and testing with the database. He includes a simple test and class showing a basic "song duration" integer response. He gets into a bit more detail on how the Eloquent code grabs the data it needs when a relation is accessed (hint: not a separate query) and how to update the test to mimic the eager loading of the duration information. He ends the post by pointing out that "nothing is free" however as, if the underlying database implementation changes, the test would start to fail regardless of it not using the database.

tagged: tutorial screencast example relation eloquent unittest stub

Link: https://adamwathan.me/2016/08/04/stubbing-eloquent-relations-for-faster-tests/

SitePoint PHP Blog:
Hassle-Free Filesystem Operations during Testing? Yes Please!
Jul 28, 2016 @ 12:24:56

On the SitePoint PHP blog there's a new tutorial posted suggesting a method for hassle-free filesystem operations during testing in your applications. Traditionally external sources, including the file system have proved difficult to test mostly because connection/state issues or conflicts.

When working with the filesystem in our tests suites, a big concern is cleaning up the temporary files after each test runs. However, if for any reason the test’s execution is interrupted before the cleanup phase, further tests might fail, as the environment has not been cleaned up.

In this post, we will use a library named vfsStream to create filesystem mocks. It’s little more than a wrapper around a virtual filesystem, which also works very nicely with PHPUnit.

They start by creating a simple FileCreator class that just uses a file_put_contents call to write data to a provided path. They start with the traditional approach in testing - just writing to the actual file and ensuring it exists. Then comes vfsStream, changing up the testing to use mocks of the directory and file and it's own checks to ensure existence. These mocks work in basically the same way as a directory/filesystem structure would without the external interaction making it much easier to test in isolation.

tagged: filesystem testing phpunit unittest vfsstream package tutorial

Link: https://www.sitepoint.com/hassle-free-filesystem-operations-during-testing/

SitePoint PHP Blog:
Testing Your Tests? Who Watches the Watchmen?
Jul 21, 2016 @ 12:10:48

In a tutorial posted to the SitePoint PHP blog Claudio Ribeiro tries to answer the question of "who watches the watchmen" (your application's tests) to ensure they're functioning as expected and are correct. In this new tutorial he introduces the Humbug mutation testing tool and how it can be used to verify your own tests.

Regardless of whether you’re working for a big corporation, a startup, or just for yourself, unit testing is not only helpful, but often indispensable. We use unit tests to test our code, but what happens if our tests are wrong or incomplete? What can we use to test our tests? Who watches the watchmen?

[...] Mutation Testing ( or Mutant Analysis ) is a technique used to create and evaluate the quality of software tests. It consists of modifying the tests in very small ways. Each modified version is called a mutant and tests detect and reject mutants by causing the behavior of the original version to differ from the mutant. Mutations are bugs in our original code and analysis checks if our tests detect those bugs. In a nutshell, if a test still works after it’s mutated, it’s not a good test.

He starts by helping you get it installed (a quick composer require) and creating a simple "calculator" test to show it in use. He then creates the test for the class with some simple testing methods for the basic calculator functionality. He then configures the Humbug installation (via a JSON config file) and executes it on the current tests, sharing the resulting output. He goes through the results showing how to interpret them and points out places where the tests could be improved.

tagged: testing unittest humbug mutation variation example tutorial output

Link: https://www.sitepoint.com/testing-your-tests-who-watches-the-watchmen/