Robert Basic has a post today showing how you can mock hard dependencies with Mockery, a mocking library for use in unit testing. In this case, "hard" refers to work around the use of "new" creating objects in hard to test places.

One problem with unit testing legacy applications is that the code has new statements all over the place, instantiating new objects in a way that doesn't really makes it easier to test the code. Of course, the easy answer to this is "Just refactor your application!", but that's almost always easier said than done. If refactoring is an option, do it. If not, one option is to use Mockery to mock the hard dependencies.

He makes use of instance mocks to show the overloading of the service without the need for a refactor. This overrides it on a more global scale, so it could have an effect on other tests. He shows how autoloading and PHPUnit's own process isolation handling can fix tis problem (though it takes more time to run the tests this way). He includes sample code of the whole process so you can easily follow along too.

The Loosely Coupled podcast has posted their latest episode today - Episode #16, Estimation is Hard. Join hosts Jeff Carouth and Matt Frost as they talk about their own experience with this difficult developer task.

In this episode, Jeff and Matt talk about the difficult task all developers are continuously faced with: estimation. They cover some examples of times they have found estimation difficult, techniques that have worked for them, and even some advice on how to deal with the stress of estimating incorrectly. Ultimately, estimation is a part of the necessary communication that must happen for a project to be successful.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3 and listening to it at your leisure. If you like the episode, be sure to subscribe to their feed and follow them on Twitter for the latest updates.

On the MayFlower blog today there's a new post looking at two ways to do software architecture (the easy way and hard way) and some of the traditional practices behind its development.

When it comes to software architecture, stuff gets funny. First we learn everything about it at university. We learn to use it as a part of our main project plan. We learn how to do risk evaluation. [...] Since we didn't have a lot of experience with software back then, the resulting architecture is a badly done, but well documented. This style of software architecture is called "Enterprise Architecture" and usually done by consultants.

They talk about delivering software versus delivering documentation and list some of the actual common reasons software architecture turns out how it does including: "I read about it in a blog", "It worked for me once" and the idea of the "Golden Hammer" of standardized structures.