Frameworks provide a tool for rapid application development, but often accrue technical debt as rapidly as they allow you to create functionality. Technical debt is created when maintainability isn't a purposeful focus of the developer. Future changes and debugging become costly, due to a lack of unit testing and structure. Here's how to begin structuring your code to achieve testability and maintainability - and save you time.

There's a few concepts they cover in the tutorial including DRY (don't repeat yourself), working with dependency injection and actually writing the tests with PHPUnit. They start with a bit of code that needs some work and use the tests to help refactor it into something that can be easily mocked (using Mockery).

Benjamin Eberlei introduced me to Phake with his recent article: it is a Composer-ready PHP library that integrates easily with PHPUnit and provides an independent Test Doubles framework, capable of producing Stubs, Mocks, and Spies. The syntax and object model reminds me of Mockito, the Java Test Double framework from the authors of Growing Object-Oriented Software. I like tools that do one thing and do it well, and after experimenting with Phake I'm using it on all new code.

He compares the two tools on a few different pieces of functionality including creating stubs, mocks and spies. Sample code is included for both sides. It's not a detailed guide by any means, but it can give you a better picture of how the two compare.

Previously in my PHPUnit tutorial series, you learned about the very powerful concept of mock objects and stub methods. This concept is central to successful unit testing, and once it fully 'clicks' in your head you will start to realize how useful and simple testing can be. There is also another thing I want to make clear: creating tests is basically a puzzle - you simply have to go step by step, making sure all the pieces fit together correctly so you can get your green. I hope to make clear what I mean by the end of this tutorial.

He assumes you already know about mock objects and introduces the concept of "stub methods" and "mock methods", noting the difference between them. He then gets into what he calls the "four pathways of getMockBuilder" and talks about the rationale behind mocking methods in the first place. He then gets into constructors and how you can work around the "bad" ones with help from mock object functionality.

If you're interested in reading the rest of the series, you can find links to them here.

When I state "as is", I truly mean the way it's being used in production. So the database call collects real data on which business logic is applied. You can see this is not a healthy situation, especially when you also have services that apply business logic on data and store it back into the database. In "Chris Hartjes wrote this one sentence that says it all: "Unit test suites are meant to be testing code, not the ability of a database server to return results". And he's right, you shouldn't use database connections when your testing business rules and functional logic.

He goes on to show a few code examples that show a pre-mocked state of testing where the Product information is pulled directly from a PDO connection. The more correct version mocks out this object, though, and overrides the "execute" and "fetchAll" methods to return mocked results.

The concept of mocking web services for testability took a little while to sink in for me. A big part of it was that my job doesn't see me consuming web services all that often, but I had an opportunity to give it a shot with SOAP. I found that I learned a lot more about testing in general having worked through this. I used SoapClient and wrapped it, so here's a little bit about some of things I learned. Hopefully you don't have to work with SOAP, but if you do you can test it pretty easily.

He walks through the mocking of the client itself and how he handled it's ability to translate function calls into SOAP method calls (using "__call") and how he mocked that. He also makes the suggestion that you actually wrap the SoapClient inside of another class rather than trying to mock the actual SoapClient. He also touches on the testing of exceptions that might be thrown by the service and how he tested those using his wrapper class.

Mockery is a PHP extension that offers a superior mocking experience, particularly when compared to PHPUnit. While PHPUnit's mocking framework is powerful, Mockery offers a more natural language with a Hamcrest-like set of matchers. In this article, I'll compare the two mocking frameworks and highlight the best features of Mockery.

He walks you through the installation of Mockery and includes the code for a sample PHPUnit test that creates a Mockery instance and mocks out a class object for testing. He moves on to more examples including:

• Adding expects for method calls (single and multiple)
• Returning values from the methods
• Calling multiple methods
• Returning different things based on parameters
• Partial mocks
• Handling constructor parameters

In my previous post I already mentioned Sebastian Jerzy Wilczyński (@dj_sebastian_w) and his uncon session "Unit Testing for Databases using fixtures and phpunit". It made me wonder how much difference it would make if you use fixtures instead of testing database interactions using predefined sets of data. Since I work a lot with Zend Framework I was looking at how I could use fixtures and mock objects to follow Sebastian's guidelines. So I gave it a try. This is what I came up with.

He illustrates with some example code - a set of database data (the fixtures) and sample tests that use the Zend Framework's mapper and table gateway functionality to work with the tables. His test then mocks out the DbTable class for the "Order" object and forces a return of the database fixture data.

If you are part of a development team, more often than not your code will also depend on code written by your teammates. But what if their code isn't available at the moment - say, your teammate hasn't finished writing it yet? Or, what if the code you need requires other external dependencies that are hard to set up? And what if you cannot test code because of other factors beyond your control? Will you just hang around, do nothing, and wait until your team is done or when everything is in place? Of course not! In this this article, I'll illustrate how to write code that works around this problem with dependencies.

He starts off by making a case for using mock objects and having them replace things that either aren't finished or depends on things that are hard to replicate (like external dependencies). He includes some example code showing them in use in a PHPUnit-based test and how to use its own mocking abilities so you don't have to manually make mock classes yourself.

The legacy code dilemma, however, is always present: you can't refactor the code before putting up some tests on it to avoid regressions and putting your application offline. At the same time, you can't easily unit test the code until some refactoring is introduced.

He suggests making copies of some files to allow you to make small changes where needed to "mock" resources in the application to prevent it from accessing the actual data sources. His method fakes HTTP requests to the script and uses the copy of the script as an internal resource. Don't worry, code is included showing how its done - a basic "ForumPosting" class that includes the needed file and wraps the output in a buffer.

If you have a PHP application that makes heavy use of objects (which is probably 95% of you reading this) then you will have objects with constructor methods in them. It is also very likely that there is some stuff going on in those constructors. So how do you test things like this?

He includes a sample constructor that creates a container, pulls out some configuration values and reassigns them to class properties. He first tests that these properties have been set correctly by mocking out the object and overriding the configuration settings in the (dependency injection) container.