In needing to test some mailing functionality in his application Adrian Schneider has come across two ways to handle it on a machine that may not have mail up and configured correctly - mail a mail transport class or sent up a pseudo mail server.

I think a staging environment is more appropriate to actually have email being sent out. Nevertheless, it has made testing any email functionality a little cumbersome. I've done a little research, and have found two ways to tackle the problem. I've also included code samples and other resources to get you started.

The first method - the transport class - uses the Zend_Mail_Transport component (and interfaces) to set the transport for the application and handle the routing from an extension of the Abstract class. The second method involves changes to system settings in the php.ini and adding in a simple script to force a forward to the right address. Windows users can also use fakemail to accomplish a similar thing.

In a new post to his blog today Sebastian Bergmann looks at a way you can test your privates (no, not that) - private methods in your classes with PHPUnit. The key lies in the Reflection API.

One question I get over and over again when talking about Unit Testing is this: "How do I test the private attributes and methods of my objects?" [...] PHP 5.3.2 introduces the ReflectionMethod::setAccessible() method to allow the invocation of protected and private methods through the Reflection API.

This method lets you, at runtime, change the access level on the method away from private or protected and down to public so the contents can be executed normally. Though he warns one thing about doing it this way - just because you can, doesn't mean it's a good thing. You application is meant to be tested in a certain way and you should probably stick to that.

If you've ever been frustrated by trying to track down browser bugs (especially on platforms you may not have access to) Brian Teeman has a tip on a site you can use to make your life a little bit easier.

With every web browser on the planet rendering differently it's a constant battle ensuring that your beautifully and painstakingly designed web site looks just as gorgeous on all browsers. Personally I build a site entirely using Firefox and only at the end of the build process do I look at it in other browsers, curse and swear and then start to fix issues.

One of the next best things to having local installations is the Adobe BrowserLab (registration required). It allows you to view the pages of a given site in either two browsers side-by-side or "onion skinned" overlaying each other to see the exact differences. The tool does not, however, allow you to interact with the sites, so it's best used for display-only problems.

Raphael Stolt has an interesting idea about PHPUnit plugin (GitHub_TicketListener) that allows you to close (or reopen) Github issues via PHPUnit tests.

Since PHPUnit 3.4.0 a new extension point for interacting with issue tracking systems [...]. The extension point has been introduced by an abstract PHPUnit_Extensions_TicketListener class, which allows developer to add tailor-made ticket listeners supporting their favoured TTS.

The "@ticket" notation that PHPUnit allows as an annotation is the key to linking together your unit tests with the new listener. Two methods, getTicketInfo and updateTicket, are used to have the listener make a cURL connection over to Github and send the request to a REST-like service on the remote side.

Brandon Savage has a suggestion for those interviewing developers for positions at their company - forget the coding test.

One thing I've noticed in hunting for a job recently is the number of companies that insist that you write them a code sample to spec. Not just any code sample, but a fully functional, complete application. This is absurd, for several reasons.

He suggests that, while submitting example code or taking a test as a part of the interview process can be a "first line" to be sure the person knows the language, they shouldn't be considered useful much beyond that. He likens it to people in other trades (like a plumber or electrician) to do their job before they can do their job...for you. Brandon suggests that the real key to a developer - how well they can learn - just can't be measured by a test like this.

In this new post to his blog today Federico Cargnelutti shows you how to use mock objects to unit test controllers in your Zend Framework application.

In this post I'll demonstrate a unit test technique for testing Zend Framework Action Controllers using Mock Objects. Unit testing controllers independently has a number of advantages: you can develop controllers test-first (TDD), develop and test all of your controller code before developing any of the view scripts and helps you quickly identify problems in the controller, rather than problems in one of the combination of Model, View and Controller.

He sets up a sample user controller and a test case to go along with it. Drop in a test for the user controller class that uses a "getMock" method to define a mock controller object for the "render" method. He also points out a few issues with this sort of testing in the Zend Framework - the return value of the Zend_Test_PHPUnit_ControllerTestCase, issues throwing exceptions with the Front Controller and a problem with the dispatcher's storage of the Action Controller.

In a recent post to The Bakery (the CakePHP resource) Jonathan Hendler has created a simple A/B test helper using the CakePHP framework and jQuery.

Knowing what is driving the user experience is key to the success of an application. Subtle changes in the interface can cause dramatic shifts in user behavior. Here, A/B tests display two (or more) language choices or color choices to a user (any HTML). Metrics are measured in two ways - 1) did the user click on the button at all and 2) how long did it take them to find it from the moment the page has started loading?

The helper tracks the user through the site and adds the results to a testing table (abtests). The code is included - model, component, controller, helper class and the jquery code to make it all work together. A few usage examples are also thrown in near the end.

In his most recent post Stuart Herbert has a suggestion that can make your development life simpler and make debugging less of a headache down the road - isolation.

If you know the code well, perhaps you can make an intuitive leap to immediately jump to where the bug is. But how do you go about tracking down a bug when intuition doesn't help? The nature of all code is that larger systems are built from smaller underlying systems and components. [...] Apart from being a strategy that allows you to work on code you've never seen before, this approach also has the advantage that it is evidence-based.

He suggests the division of your application down into the base level of components, sets of "logical points" that make it both simpler to test and more modular for the future. He gives an example of tracking down a bug in a system like this and notes that, with a good set of tests, it can be much faster than some of the other, more traditional debugging methods.

New from the BiGiTSS blog there's a reminder for those looking to upgrade to the latest PHP 5.3 release - is your code ready?

If you are planning to upgrade to PHP 5.3 from PHP 5.2.x then you must think twice before you really do it. There are few things you should take care of. Recently last week I tried upgrading one of the web-server to PHP 5.3 from PHP 5.2.9 and it was not a good idea which I came to know later on.

They mentions all of the warnings/errors they found on the upgrade and spotted an issue with one of their external libraries that caused them to have to roll back that as well. Be sure to check the deprecated list before you try moving up your PHP version and ensure that things like the __toString override don't catch you and your application off guard.

In this latest post in his "Peer Review" series Brandon Savage looks at things that can make the sample code he's been working with easier to test.

Now that we've worked out the abstraction issues and the logic questions, we should take a moment to focus our attention on a few of the issues relating to the architecture and testability of the class we've worked out.

He mentions changes to a call to get_included_files, a bit of code requiring magic quotes, and changes to the code to make writing using tests simpler (like injecting objects rather than creating them and writing a unit test every time a bug is found so it doesn't happen again).