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

Brandon Savage:
Don’t write useless unit tests
Jan 17, 2018 @ 10:44:42

Brandon Savage has a quick post to his site sharing some advice around the testing of your application, more specifically around unit tests: don't write useless unit tests. He starts with an example of a test that, while moving the project closer to the 100% coverage number, is mostly useless.

Too often, in the search for 100% unit test code coverage, I see tests like this get written. They don’t serve a practical purpose, except to meet the test coverage goal. Worse, they don’t actually improve the quality of the application.

Instead of writing a unit test here, we would be better served by writing an integration test, or a functional test. These tests would require us to interact directly with the database, but would provide far more valuable information about the health and status of our application. A useless unit test provides us with little if any benefit; a useful functional test provides us with tremendous advantages.

He includes the code for the test and talks about what's wrong with the approach and how it could potentially be handled better. He suggests that writing good, useful tests requires both skill and determination and the avoidance of tests that actually increase the quality of the overall test suite.

tagged: useless unittest tutorial example functional test

Link: https://www.brandonsavage.net/dont-write-useless-unit-tests/

Sergey Zhuk:
Test Coverage: Integration Between CodeClimate and Travis CI
Jan 11, 2018 @ 09:42:11

In a post to his site Sergey Zhuk shows you how to get up and running on Travis-CI and Code Climate for generation unit test coverage with an integration between the two services.

When you maintain an open-source project it is considered a good practice to have a high test coverage, so the community can feel safe about using your code in their projects. There are some services that can analyze your code quality and provide some feedback about it. One of the most popular is Code Climate. This service doesn’t run your tests, but you can use one of CI tools to run them and then send their result to Code Climate. This article will show how to use Travis CI to run your tests and CodeClimate to get your test coverage.

The rest of the tutorial is broken down into five steps (well, five-ish - some have sub-steps):

  • Get Your CodeClimate Reporter ID
  • Add Your Code Climate Token To Travis CI
  • Add CodeClimate Test Reporter Package
  • Update phpunit.xml
  • Update Travis CI Config To Send A Report

Each section includes the configuration changes to the .travis.yml or phpunit.xml configuration files you'll need to make to connect the services and generate the reports automatically.

tagged: unittest coverage metric travisci codecliemate integration automatic tutorial

Link: http://sergeyzhuk.me/2018/01/11/travis-with-codeclimate/

Sameer Nyaupane:
PHP Test Driven Development Part 2: Unit Testing
Dec 18, 2017 @ 13:39:07

On the HackerNoon site Sameer Nyaupane has posted the second part of his series on test-driven development in PHP focusing on unit testing and sharing some best practices around creating effective tests.

All right, welcome to part 2 of “PHP Test Driven Development” series. Today we will go through the PHPUnit setup in detail.

We will be using the Laravel framework to make it easier for us to get started. It will also help me to show you how to do testing for real life applications. I will assume you have used Laravel before. This will help me focus on the testing side and make the tutorial easier to grasp.

The tutorial then walks you through the setup of a new Laravel project and the inclusion of PHPUnit before getting into the tests themselves. It also shares a PHPUnit configuration example and the creation of an example tests with a simple assertion.

tagged: tutorial testdriven development tutorial series part2 unittest

Link: https://hackernoon.com/php-test-driven-development-part-2-unit-testing-c327ba3fbf14

Robert Basic:
Mockery return values based on arguments
Dec 13, 2017 @ 15:13:55

Robert Basic has a new post to his site where he shows how to use the Mockery unit testing too to return different values for different arguments. Fortunately there's something already built into the tool to help handle this.

Sometimes when working with Mockery mock objects, we want to tell a mocked method to return different values for different arguments. It is a rare occasion when I need this feature, but every time I need it, I’m happy it’s there.

The feature that allows us to return different values based on arguments is the andReturnUsing Mockery method, which takes a closure as an argument.

He includes examples of the use of this andReturnUsing method in mocks and showing that there's more than one way to accomplish the same kind of goal. While this is a useful method to use when needed he points out that refactoring the code under test is probably a better way to go instead.

tagged: mockery unittest arguments return value tutorial

Link: https://robertbasic.com/blog/mockery-return-values-based-on-arguments/

TJ Miller:
An Approach to Testing Middleware
Nov 29, 2017 @ 09:06:19

TJ Miller has posted an article where he shares some suggestions about testing middleware in your applications. Since middleware is usually only executed as a part of the normal request/response cycle it is difficult to test in isolation.

I’ve always tested middleware in one of two ways, a unit test with mocks and asserting the callback in the handle method or integration tests on application routes.

[...] I wanted to find a simple approach that verified the following: middleware is active and configured correctly (global, group, single use) [and that the] middleware is functioning correctly

He briefly discusses the difference between unit testing and integration testing before showing how to set up unit tests for a Laravel-based middleware: a check for a JSON response, testing to ensure logging is working as expected and that a middleware is correctly assigned to a route.

tagged: testing unittest integration middleware laravel tutorial

Link: https://medium.com/@sixlive/an-approach-to-testing-middleware-c547fc942848

Mark Baker:
Extending final Classes and Methods by manipulating the AST
Nov 20, 2017 @ 10:38:32

Mark Baker has an interesting post to his site where he shares a suggestion for making it easier to create unit tests for some of the more difficult parts of your unit tests. In the article he shows how to extend final classes and methods by manipulating the AST (abstract syntax tree structure) of the current code under test.

We know that we should always write unit tests for our code, and mock dependencies; but that isn’t always easy when we need to mock classes define as final, or that contain final methods. This isn’t normally a problem when we’re only working with classes within our own libraries and applications, because we control whether they are final or not, and we can type-hint these dependencies to interfaces. However, when the dependencies that we use are from external libraries, we lose that control; and it can become harder to test our own classes if we do need to mock final classes and they haven’t been built to interfaces.

He talks about how one tool, Mockery, allows some of this with its functionality but can still cause issues when mocks are passed instead of actual class instances. He then starts on a solution he has been trying to implement - a mocking library that makes use of the PHP_Parser package to make it possible to modify the structure of the code itself, not just put a wrapper (mock) around it. He includes a bit of code showing how to use that and the BetterReflection library to do some class introspection, locate files for testing and how to the tool to "de-finalize" a class (make it no longer "final").

tagged: extend class method manipulate ast testing unittest final mockery tutorial

Link: https://markbakeruk.net/2017/11/19/extending-final-classes-and-methods-by-manipulating-the-ast/

Exakat Blog:
Get ready for PHP 7.2
Nov 20, 2017 @ 09:56:21

With the final release of PHP 7.2 coming on the horizon the Exakat blog wants to be sure you and your code are prepared for some of the changes. In this new post they share things to change and improvements to expect in this latest version of the PHP language.

PHP 7.2 is around the corner, and shall be out soon, thanks to the hard work of @RemiCollet), Sara Golemon (@saramg) and countless others that run tests and submit bug reports. PHP 7.2 is already RC6, and the documentation has even been updated : it is high time to get ready for PHP 7.2.

We have been hard at work, at @Exakat, to prepare the migration analysis. This is our take on this upcoming task.

He's broken the changes coming down into a few categories based on the actions required and what you can do to prepare: Know, Lint, Static (Analysis), Unit testing and Logging. A chart is then included showing each of the changes, which category they fall into and links to more information about them and what has been updated (or added).

tagged: php72 preparation lint staticanalysis unittest logging update version language

Link: https://www.exakat.io/get-ready-php-7-2/

Stefan Koopmanschap:
Your unit test methods need docblocks too
Oct 12, 2017 @ 11:48:02

In a post on his site Stefan Koopmanschap suggests something that, while not as commonly done as writing docblocks for the actual code, could help with a better understanding of the application's tests: writing docblocks on tests too.

If you've met me at any time in the previous 20 years and you discussed unit testing with me, chances are pretty big that I'd have told you that your test methods in your unit tests don't really need docblocks, because the test methods would be named in such a way that they were descriptive.

[...] Tests can be hard to real though, especially (but not exclusively) when testing legacy code. You may have lots of mocks to configure, for instance, or you may have several similar tests that are testing specific situations, edge cases or bugs you found along the way that you wanted to test before you them.

[...] Documentation is important. It lowers the bus factor, makes it easier to on-board new developers (or temporary external developers, waves) and makes you think about your own code in a different way. We're (getting?) used to documenting our software, but why not document our tests by giving it a bit more context?

He starts by talking about his process for testing (outline the desired tests then fill them in) and how adding docblocks helped him avoid a "nonsensical" test that wouldn't have provided much value. He then briefly discusses what would be useful to document in the test docblocks and provides some examples to illustrate. Finally he suggests something called "Docblock Driven Testing" where the docblock descriptions help to define what is to be tested and help to make more human-readable sense of what can be tested effectively.

tagged: unittest method docblock opinion testing definition

Link: https://leftontheweb.com/blog/2017/10/11/your_unit_test_methods_need_docblocks_too/

Sammy Powers:
Finding & patching a bug in php-src
Oct 10, 2017 @ 12:17:06

Sammy Powers has a new post to his site today showing you how to find and patch a bug in php-src, the source of the PHP language itself.

While he does provide all of the details in the post he also has created a screencast that walks you through the whole process as well. He breaks up the process into the different steps of the process:

  • Find the bug (his was with the JSON handling)
  • Submit a bug report (on bugs.php.net)
  • Make a patch
  • Run GDB
  • Make a test
  • Submit a PR and update the bug

He includes code and descriptions along the way and finishes out with further suggestions about feedback on the PR and how his own situation finished out.

tagged: phpsrc find patch bug pullrequest unittest patch tutorial

Link: https://www.sammyk.me/how-to-find-and-patch-a-bug-in-php-source-php-internals

Facile.it Engineering Blog:
How to gradually upgrade toward PHPUnit 6 with namespaced classes
Sep 13, 2017 @ 11:56:03

On the Facile.it Engineering blog there's a recent post sharing some tips on how to gradually upgrade your PHPUnit tests to work with version 6 of the popular PHP unit testing tool.

In the latest months I wrote multiple times, in different projects, code migrating PHPUnit toward major version 6. This upgrade is harder than the previous one, since in this version it was introduced a big breaking change: all classes got (finally!) namespaced.

This means that any usage of those classes in your project needs to be updated. [...] In this article I will explain which steps I applied during those migrations, highlighting the most frequent hiccups.

He then start with "the easy one" to take care of the refactor: updating tests to replace the "PHPUnit_*" classes with the namespaced versions. With those out of the way, he talks about "the bumpy one" to handle: modifying test listeners to work with the new PHPUnit structure. Once these are taken care of you can then make the move up to PHPUnit 6 and PHP 7 (if you're not there already) full time.

tagged: phpunit upgrade version unittest phpunit6 php7 tutorial

Link: https://engineering.facile.it/blog/eng/phpunit-upgrade-namespace/