In the first article in this series, I wrote about the problems with testing static methods in classes, and showed a few approaches that allow us to write mocks for statics. Testing classes where we have static properties is a lot harder to manage, because any changes made in any test to those properties are global, across the entire test suite, not simply the test that we are running. Static properties are part of the global state, and we can’t simply
tearDown() those changes in the way that we do with instances — at least we cannot easily do so if the property has a visibility of private or protected.
Posted in PHP
Tagged PHP, Static, Testing
If you’ve read my previous post (Discharging Static #1), then you’ll know that recently I’ve been exploring different approaches to creating test doubles for statically called methods, and other testing problems, and had begun to look at Michael Bodnarchuk’s AspectMock library as an alternative to Mockery. Much as I like Mockery, and have no issues with it when tests are run standalone, it can be problematic when running the whole test suite; whether upstream tests have already autoloaded the classes that you need to mock, or breaking downstream tests, even when calling
Mockery::close() as part of the PHPUnit
AspectMock is a stubbing/mocking library written as part of the Codeception test framework, but which will also work with PHPUnit; and which provides functionality that not only allows mocking of both static and instance methods, but can also mock functions (including PHP’s built-in functions, as well as userland functions). It can achieve all this because it is built on the The Go! AOP framework for PHP. Exploring how this worked introduced me to the AOP (Aspect Oriented Programming) paradigm; and I feel like I’ve taken the red pill, followed the white rabbit down the hole, and entered the surreality of Wonderland.
Posted in PHP
Tagged AOP, Aspect, Go!, PHP
It’s been seven years since Kore Nordmann first published “static considered harmful” on his blog, explaining the problems with using static method calls in classes, and the difficulties that they cause when trying to test that class. Seven years on, and those difficulties are still the same, and there is still new code being written using static calls despite that knowledge; but it’s often a more severe problem in legacy code with little or no unit tests.
So why exactly are static calls so bad? If you’ve read Kore’s article, then you probably have a good idea already; but what that article doesn’t cover is approaches that we can use to make the code testable.
Posted in PHP
Tagged PHP, Static, Testing
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.
Why might we want to do this? One possible reason is that it gives us the ability to test the internal methods of an object in isolation from other code within the public methods that we would normally 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 adn they haven’t been built to interfaces.
Libraries like Mockery do provide a proxy approach to mocking final Classes, which works well, but with one major limitation.
In a compromise between mocking functionality and type safety,
Mockery does allow creating "proxy mocks" from classes marked
final, or from classes with methods marked final. This offers
all the usual mock object goodness but the resulting mock will
not inherit the class type of the object being mocked, i.e. it
will not pass any instanceof comparison.
Unfortunately, this limitation still causes problems when passing the mock to a method with type-hinted arguments to the class rather than to an interface if we need to Dependency-inject the mock; or if we don’t have much choice because the the final class wasn’t implementing an interface. Library writers take heed if you define any of your classes as final; always write them with an interface that can be type-hinted.
So is there any way we can create a test double that matches type-hinting when we need to pass it into the class that we’re testing? I’ve been looking at an alternative approach to mocking that does allow me to create a test double that extends a final 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?
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.