Matthias Noback has posted the second part in his look at a better PHP testing experience, focusing this time on picking test doubles wisely. Test doubles are a more general term for what most developers who test code might call a "mock".

In the introduction to this series I mentioned that testing object interactions can be really hard. Most unit testing tutorials cover this subject by introducing the PHPUnit mocking sub-framework. The word "mock" in the context of PHPUnit is given the meaning of the general concept of a "test double". In reality, a mock is a very particular kind of test double. [...] Each type of test double has its own merits and it is vital to the quality of your test suite that you know when to use which one.

He builds on the "non-assertion centric" approach he talked about in the first part and how a similar problem could be caused by the large amount of work needed to create complex mocks. He points out that having to create them in a specific way and the mocks being a bit difficult to use can make the tests fragile and easily broken. He looks at a few different kinds of test doubles (mocks, dummies, spies) with code examples for each for added clarification. He also makes two recommendations for testing instead of complex mocking: create the actual mock classes instead of just mocks and don't overuse mocking.

Brandon Savage has made a few suggestions that can help you with one of the most important parts of any development project - picking the right tool for the job.

You'd never dig a drainage ditch with a pitchfork, or plug a drywall hole with chewing gum. Instead, you'd pick an appropriate tool and you'd use it to accomplish the job (a shovel, or some spackle, for example). So why do software engineers often spend so much time fixing problems with the wrong tools at hand?

He includes three common issues and ways you can overcome/stay away from them:

• Lack of knowledge regarding available tools.
• Inability to implement solutions due to lack of resources.
• Unwillingness to implement a solution.

Of the three, the last one is possibly the most scary - don't let personal feelings or your dedication to Tool X be your undoing and hurt your application in the long run.

Scott Johnson shares a new podcast that he's whipped up on his blog today with his opinions on why the engineers should get to pick what they use (specifically mentioning Rails or PHP).

The podcast last about fifteen minutes and looks more at the general topic of allowing the developers themselves to choose the tools they will be wokring with. More often than not, especially in the corporate world, technologies are forced onto someone with no real choice in the matter. Check out what Scott has to say on the subject.

Scott Johnson shares a new podcast that he's whipped up on his blog today with his opinions on why the engineers should get to pick what they use (specifically mentioning Rails or PHP).

The podcast last about fifteen minutes and looks more at the general topic of allowing the developers themselves to choose the tools they will be wokring with. More often than not, especially in the corporate world, technologies are forced onto someone with no real choice in the matter. Check out what Scott has to say on the subject.