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

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/

Freek Van der Herten:
A tool to automatically rerun PHPUnit tests when source code changes
Aug 04, 2017 @ 10:12:37

In this post to his site Freek Van der Herten shares information about a tool that can help to streamline your development workflow. The phpunit-watcher tool mimics tools from other languages to watch for changes in the source of your application and automatically execute your PHPUnit tests when modifications are made.

In the JavaScript world Jest, built by Facebook, is an excellent tool to run tests. Not only can it automatically rerun your tests when source code changes, but there’s also an interactive mode where you can set a filter on which tests to run while the tool is running. Would it be great if we could have these awesome features while working with PHPUnit?

Our newly released phpunit-watcher tool provides a Jest like experience. You can simply install it by running composer global require spatie/phpunit-watcher.

Once the tool is installed it can then be run from the command line, sitting and waiting for changes to the target files and directory. It's configurable in case you don't follow some of the usual package directory structures and can be filtered to only run on certain filename matches. This can also be done manually (real-time) via the tool. Screenshots are included showing the tool in action too.

tagged: phpunit watcher automatically execute unittest package

Link: https://murze.be/2017/08/tool-automatically-rerun-phpunit-tests-source-code-changes/

Sammy Kaye Powers:
Writing tests for PHP source (Series)
Jul 21, 2017 @ 11:21:48

Sammy Kaye Powers has a series of posts over on his site introducing you to testing the PHP language with .phpt tests. So far he's introduced the topic, shown how to run the tests and debugging failing tests.

If you've ever wanted to get involved with PHP internals, writing tests is a great way to get your foot into the door. The tests are written in PHP so you don't even need to know C to get started.

Each of the posts also comes with a screencast, narrated by Sammy, showing the information presented in the tutorial:

There's more to come in the series as he still plans to teach about how to fix current tests and how to eventually create your own. Stay tuned to his site for more tutorials in the series.

tagged: test unittest phpt language source series part1 part2 part3 part4

Link: https://www.sammyk.me/compiling-php-from-source-writing-tests-for-php-source

SitePoint PHP Blog:
How to Write JavaScript-Style Test Watchers in PHP
Jul 20, 2017 @ 13:18:43

On the SitePoint PHP blog there's a new tutorial that talks about creating "watchers" in your PHP code similar to the ones that the Javascript world has used to detect changes in files and automatically perform actions.

In the land of JavaScript, it’s not uncommon to preprocess source code. In the land of JavaScript, developers write in syntax not widely supported, and the code is transformed into syntax that is widely supported, usually using a tool called Babel.

In order to reduce the burden of invoking the transformation scripts, boilerplate projects have started to include scripts to automatically watch for file changes; and thereafter invoke these scripts.

These projects I’ve worked on have used a similar approach to re-run unit tests. When I change the JavaScript files, these files are transformed and the unit tests are re-run. This way, I can immediately see if I’ve broken anything.

The author (Christopher Pitt) then shows how to create the project and make use of pre-processing and some sample scripts to run tests against. He shows how to set up the test configuration and provides an example test. Finally he includes a script that's used by the "watcher" to recompile the scripts before the tests are executed. To to the watching, he uses the yosymfony/resource-watcher package and a long running PHP script ("watch-test").

tagged: watcher javascript tutorial unittest phpunit resourcewatcher

Link: https://www.sitepoint.com/write-javascript-style-test-watchers-php/

Jason McCreary:
You changed the code, you didn't refactor the code.
Jul 13, 2017 @ 11:16:27

Jason McCreary has a post with an interesting perspective about code refactoring and what it means to refactor. He suggests that just changing code isn't refactoring and that it's more about changes in the observable behavior.

There was a good discussion on Twitter yesterday regarding a code contribution to the Laravel framework. It ended with some good questions about the distinctions between “refactoring” vs “changing” code.

While I want to focus on these distinctions, let’s first focus on the code change.

He gives an example of some code from the suggested change that reduced the number of lines in a before function call that still satisfied the requirements defined by the unit tests. He suggests that, while this change allowed the method to work as expected, it was more of a "change" than a "refactor". He suggests that because the code internal to the method changed that the "observable behavior" changed because of a special case with the return value. Existing tests didn't catch the change so it was assumed the refactor was successful even when it wasn't. Adding this test and fixing the issue then resulted in a true refactor and not just a change.

Given the symbiotic relationship between refactoring and testing, some consider the tests to be the requirements. So if all tests pass, you met the requirements. I think that’s a slippery slope. For me, the definition of “refactoring” again provides the answer through its own question - did we change the observable behavior?
tagged: code change refactor opinion unittest patch laravel

Link: https://jason.pureconcepts.net/2017/07/refactor-vs-change-code/

QaFoo Blog:
Refactoring Singleton Usage to get Testable Code
Jul 11, 2017 @ 12:22:07

The QaFoo.com blog has a new post sharing a helpful hint on refactoring singletons to make them more testable. Singletons and notoriously difficult to test due to how it can potentially return an unexpected version of an object.

So your code base is littered with singletons and using them? Don't worry, you can start refactoring them out of your code base class by class and introduce increased testability at every step. This strategy is very simple to implement and the probability of breaking your code is very low, especially when you are becoming more experienced with this technique.

They give an example of a service class that uses a singleton to get an instance of the Solarium_Client class via a static method call. They show how to refactor this out into a separate method and then use the "lazy initialization" pattern to only use the singleton if the property isn't already defined. This then allows you to use a setter to inject your own client during testing (a mock most likely).

tagged: refactor testing unittest mock singleton property lazy initialization

Link: https://qafoo.com/blog/107_refactoring_singletons_testability.html