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

Matthias Noback:
Mocking at architectural boundaries: persistence and time
Feb 22, 2018 @ 11:07:35

In a new post to his site Matthias Noback takes a look at unit testing your code and how it can be "dangerous" if you use mocking/doubles in the wrong way (not effective testing). Instead, he makes the recommendation to mock at architectural boundaries, specifically looking at mocking persistence and time handling.

More and more I've come to realize that I've been mocking less and less. The thing is, creating test doubles is a very dangerous activity.

[...] For example, by creating a test double for the EntityManager, we're assuming that it will work well with any objects we'll pass to it. If you've ever debugged an issue with an EntityManager, you know that this is a bad assumption. Anything may go wrong: a mistake in the mapping, missing configuration for cascading persist/delete behavior, an issue with the database credentials, availability of the database server, network connectivity, a missing or invalid database schema, etc.

He then gets into the concepts behind mocking across the "architecturally significant boundaries" and what kind of functionality this involves. He then gets into the two different examples sharing some of the basic concepts and test examples for evaluating persistence and time handling. He finishes up with a look at some of the potential consequences ("outcomes" is really a better word) of refactoring your tests and code to follow these ideas.

tagged: mock unittest architectural boundary persistence time tutorial

Link: https://matthiasnoback.nl/2018/02/mocking-at-architectural-boundaries-persistence-and-time/

Robert Basic:
Mockery partial mocks
Feb 05, 2018 @ 11:18:08

Robert Basic has a quick post to his site where he shows how to use partial mocks in Mockery, a useful tool for unit testing in PHP applications.

In dealing with legacy code I often come across some class that extends a big base abstract class, and the methods of that class call methods on that big base abstract class that do an awful lot of things. I myself have written such classes and methods in the past. Live and learn.

One of the biggest problems with this kind of code is that it is pretty hard to test. The methods from the base class can return other objects, have side effects, do HTTP calls…

He gives an example of a model that includes a method returning a database connection. In the child class of this the method that he's wanting to test includes a call to this method, making it difficult to test in isolation. He then shows how to make a partial mock of the child class that, be definition, returns a mocked PDO instance instead of the real PDO instance. All other methods will be passed through to the real class.

tagged: mockery unittest partial mock class abstract tutorial

Link: https://robertbasic.com/blog/mockery-partial-mocks/

Anna Filina:
Testing Legacy PHP Scripts
Jan 30, 2018 @ 11:56:23

Anna Filina has a quick post to her site with some recommendations around testing legacy PHP scripts giving an example of a challenge to test a controller in isolation from the rest of the application.

I gave myself a challenge: to test a legacy "controller" in isolation, yet with minimal impact on the original code.

She starts with the example code she'll be testing and then works through the steps to effectively test it:

  • isolating it from the other functionality in the application
  • mocking a statically called method
  • requiring necessary files
  • executing the controller under test

The post ends with the test class she created showing how to evaluate the result of a call with one invoice in the billing system. She makes one comment at the end to answer the question "why not just refactor" but points out that, especially in larger legacy applications, that's just not always an option.

tagged: testing legacy script tutorial isolation mock unittest phpunit

Link: https://afilina.com/testing-legacy-php-scripts

Mark Baker:
Closures, Anonymous Classes and an alternative approach to Test Mocking (Part 4)
Jan 23, 2018 @ 10:21:14

Mark Baker has returned with a new part of his series looking at the use of anonymous classes and closures as an alternative to the typical test mocking functionality. In this latest part (part four) he talks more about the "SpyMaster" class created in the previous article and how it can be refactored to provide the spies with a "mission".

In a prior article in this series, I described the use of a SpyMaster Class to create proxy spies as anonymous classes, that allow external visibility (and potentially update) of protected and private properties within an object. The same basic principle of a spy can also be used to create a proxy that gives us access to execute the private and protected methods of an object.

[...] Unlike the original SpyMaster that I wrote about last July, we’re going to take a slightly different approach here, providing our spies with a “mission”.

He first shares the code for the old class and covers why it was useful. He then moves on to the refactor, showing how it defines the "mission" (what to mock) and an "invoker" that helps with the actual execution. He gives an example of this new class in use, performing an "infiltration" on a sample object and calling previously protected methods directly.

tagged: closure anonymous class alternative mock tutorial part4 series

Link: https://markbakeruk.net/2018/01/23/closures-anonymous-classes-and-an-alternative-approach-to-test-mocking-part-4/

Mark Baker:
Closures, Anonymous Classes and an alternative approach to Test Mocking (Part 3)
Sep 19, 2017 @ 11:58:39

Mark Baker has posted the third part of his series looking at an alternative way to handle mocking in the tests for your PHP application. In this latest part of the series he shows how to modify one of PHPUnit's own mocking examples to use an anonymous class.

I have heard people say that you shouldn’t test abstract classes or traits, only the concrete classes that implement or use them. I don’t follow that approach: unit testing is all about testing in isolation from anything that might affect those tests. Testing a concrete class that implements an abstract one, or uses a trait, means that the abstract class or trait is no longer fully isolated, but is being tested within the scope of the whole of that concrete class. We should still always test concrete classes as well; but we should also test the abstract classes and traits as individual units.

So just how do we test something that cannot be instantiated on its own?

He shares one tactic that some developers use - a class designed only for testing - but suggests that this "pollutes" the codebase. Instead he shows how to replace mocking for traits and abstract classes with an anonymous class that's more "disposable". He also shows how to modify this approach to handle calling protected methods in the class the anonymous class extends.

tagged: closure anonymous class alternative mock tutorial part3 series

Link: https://markbakeruk.net/2017/09/18/closures-anonymous-classes-and-an-alternative-approach-to-test-mocking-part-3/

Mark Baker:
Closures, Anonymous Classes and an alternative approach to Test Mocking (Part 2)
Aug 11, 2017 @ 10:44:19

Mark Baker has posted the second part of his series covering the use of closures and anonymous classes as an alternative approach to mocking in your unit tests. In part one he introduced some of the basic concepts behind their use and in this latest post he focuses on "different approach to using an Anonymous Class to verify the values of object properties".

The last time I posted here, I was writing about Anonymous Functions and how they can be bound to any object (or class) to execute as though they are a method within the scope of that class (Closure Binding as an alternative to “use” variables); and in the first article in this series, I looked at using a Closure to access private and protected properties of an object.

I was going to write this particular article about using simple Anonymous Classes to create test doubles for Unit Testing – and may well return to that topic in a future article in the series – but Matt Brunt has written a good post on that topic already, so instead I’m going to focus on a different approach to using an Anonymous Class to verify the values of object properties that we otherwise couldn’t see directly when testing a class.

He goes on to talk about some ideas from the Java ecosystem around nested classes and scoping. He then shows how, with closure binding, the same kind of effect can be created in PHP testing. He includes the code for an example of a class that coverts distance measurements. He then introduces his "SpyMaster" utility class that "infiltrates" the class under test and attaches the closure providing the needed point for testing. He finishes up the post talking about this functionality and how the technique can be used in many places, not just testing class constructors.

tagged: closure anonymous class alternative mock tutorial part2 series

Link: https://markbakeruk.net/2017/07/30/closures-anonymous-classes-and-an-alternative-approach-to-test-mocking-part-2/

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

Adam Wathan:
Detecting Out of Sync Mocks in Mockery
Apr 05, 2017 @ 11:14:41

Adam Wathan has shared a new post on his site with advice on finding out-of-date mocks when using the Mockery mocking tool in your testing.

If you're not careful, it's easy to find yourself in a situation where a test double has gotten out of sync with the actual class or interface it's mocking.

In this quick screencast (taken from my Test-Driven Laravel course), I walk through how I use a little-known Mockery feature to help track down these issues and make sure I'm not mocking methods that don't exist.

The quick screencast (about 4 minutes) gives an example of locating the issue when a "Ticket" class is refactored. While the tests still pass, it can cause issues in testing and can be difficult to find. Mockery comes with a configuration option (in 1.0 alpha) to disable the mocking of methods that don't exist on the original object. He shows how to disable this feature and what the resulting error looks like when the tests are run.

tagged: mockery screencast unittest mock sync class disable configuration

Link: https://adamwathan.me/2017/04/03/detecting-out-of-sync-mocks-in-mockery/

Robert Basic:
PHP traits to create test doubles
Apr 04, 2017 @ 10:47:15

In a new post to his site Robert Basic shows how to make use of traits to create test doubles in your unit testing practice. He sees them as a simple method for keeping tests clean and not having mocks/fakes/etc. all over.

Keeping your application or library code well organized, easy to follow, and read is important. Your test code should not be exempt from those rules, you should follow good testing conventions.

One part of my tests that I feel like that are out of control are the test doubles. Dummies, fakes, mocks… Seems like they are everywhere and that I keep writing the same ones over and over again. I do follow some good practices on how to reduce code duplication in my tests, but these mocks… Ugh.

He starts with a simple example, showing a test that evaluates the result of a transaction being executed (true or false). However, he describes the eventual "creep" of the tests as more are added and, with each, more "transaction" object instances are required. He suggests refactoring the creation of those doubles into traits where the class they're called from can inherit them and test setup is a bit cleaner. He proposes a "trait for every double" so that they can be easily included as needed and without conflict.

tagged: traits unittest double mock tutorial example setup object

Link: https://robertbasic.com/blog/php-traits-to-create-test-doubles/

Weebly Engineering Blog:
PHPUnit - Mocking the Filesystem with vfsStream
Feb 24, 2017 @ 10:52:23

On the Weebly Engineering blog there's a new post showing you how to combine PHPUnit and vfsStream to mock out file system operations away from the actual file system.

Recently I found myself needing to write tests for a small class that read from a json file. The class needed to read a json file, validate its existence and content, provide a method to inform the user if a certain key exists, and provide a method to retrieve a value for a given key.

[...] Testing this class in isolation can be tricky because it currently has a dependency on the file system. Storing test json files to test this class would work, but is not ideal because it leaves a dependency on the file system in your tests. As with any external resource, there might be intermittent problems with the file system and could result in some flaky tests. This is where vfsStream shines.

The post includes an example class under test that pulls in the JSON files and operates on the contents. To make the testing easier they introduce vfsStream, a wrapper that allows for a virtual "file system" that can be operated on through the usual interfaces. They include an example of its use in a test on the same class making it easier to check the JSON based on a pre-defined value (essentially a mock of the file and its contents).

tagged: vfsstream unittest mock filesystem tutorial

Link: https://medium.com/weebly-engineering/phpunit-mocking-the-file-system-using-vfsstream-5d7d79b1eb2a#.vdie5rhyr