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

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

QaFoo Blog:
Five Tips to Improve Your Unit Testing
Jun 13, 2017 @ 10:52:54

The QaFoo blog has posted a new article sharing five tips to improve your unit testing of your PHP applications. Even if you're a testing veteran, there's some helpful hints in here for you.

After you got the hang of unit testing there is still so much space for improvement. In this post I want to share five tips with advanced testers I have seen to influence testing in the right direction.

Their list of five tips includes advice about what you should consider as a "unit", refactoring test code and writing tests for bugs. Each topic includes a brief description of the suggestion and clear steps to follow when integrating it into your testing workflow.

tagged: unittest tips improvement advice unit logic refactor utilities bugs

Link: https://qafoo.com/blog/105_five_tips_improve_unit_testing.html

thePHP.cc:
Testing Keeps Me From Getting Things Done
May 25, 2017 @ 09:52:29

On thePHP.cc site they have a new post that tries to refute a common claim from developers when it comes to testing: testing keeps me from getting things done. The post is a response to an email to the group about testing asking where the real value is in applications versus libraries/tools.

To successfully develop software means to work target-oriented. These targets should be derived from acceptance criteria that are reconciled with the business. Without clear targets – we mean at a task level, not project or annual targets – the developer runs the risk of getting lost in work. Most importantly, he does not know when he is done with a task.

It is prudent to document and verify acceptance criteria through automated tests. One way or another, the targets have to be defined before production code gets written. This is test-driven development, whether you want to call it that or not.

The response goes on to talk about how, with tests written after the code has already been written (legacy code), it's not always clear what the original intent was resulting in lost context. It also compares two of the main types of testing - integration and unit - and the place each has in an overall testing strategy.

tagged: testing unittest reply integration opinion application

Link: https://thephp.cc/news/2017/05/testing-keeps-me-from-getting-things-done

QaFoo Blog:
Testing the Untestable
May 02, 2017 @ 12:32:55

On the QaFoo blog there's a new post sharing a method for testing the untestable - file upload handling in your application.

A long time ago I wrote a blog post about Testing file uploads with PHP where I have used a CGI PHP binary and the PHP Testing Framework (short PHPT), which is still used to test PHP itself and PHP extensions.

Since the whole topic appears to be still up-to-date, I would like to show a different approach how to test a fileupload in PHP in this post. This time we will use PHP's namespaces instead of a special PHP version to test code that utilizes internal functions like is_uploaded_file() or move_uploaded_file().

They update the previous method to use the namespacing built in to PHP to "trick" the test into using a method from a local namespace first. The provide the code they'll be testing and a unit test to try and evaluate its result. The tutorial then shows how to use the namespaces to define is_uploaded_file and move_uploaded_file functions that override the defaults. These are used instead of the base level PHP ones making it easier to test the results of the mocked functions rather than the originals.

tagged: testing untestable fileupload unittest namespace tutorial

Link: https://qafoo.com/blog/102_testing_the_untestable.html

BitExpert Blog:
Mocking callables in an Expressive app
May 01, 2017 @ 11:18:28

On the BitExpert blog Stephan Hochdörfer shows you how to mock callables in a Zend Expressive application based on a way he found during his own unit testing.

While working with Zend Expressive, a PSR-7 middleware microframework, I wanted to apply some unit testing with a nice coverage to my middlewares. Middlewares are called by the __invoke method if you provide them as an object and not as a closure. [...] Additionally, my middleware implementation does some stuff, but the middleware itself does not return a response, which is fine. Instead, my implementation calls the $next middleware in line.

He finishes the post with a quick example of how to mock out this $next call in his testing using the createPartialMock functionality in PHPUnit. He uses this method to create a mock that covers the __invoke method and returns a ResponseInterface instance of his choosing.

tagged: zendexpressive mocking phpunit unittest invoke callable testing tutorial

Link: https://blog.bitexpert.de/blog/mocking-callables-in-an-expressive-app/