Adding conditional toggles into methods for running tests

Question

We've recently started to write tests for our fairly large PHP code base - using PHPUnit we are writing unit and integration test for our models and controllers.

What's the concensus in setting a boolean toggle that states whether a class is in TEST_MODE that alters the behaviour of a method?

ie: An email helper function - we don't need to send out an email during a test and we're not testing the mail server, just that that method has been called.

if (self::TEST_MODE) {
 return true;
}

I'm already going off this idea - I don't think adding extra checks throughout the codebase for testing is an elegant solution.

But in this example for instance - what would be a good way to check the email has been sent?

• S.Lott: "adding extra checks throughout the codebase for testing" is not inelegant. It's flat-out wrong. It perverts the notion of testing, since you're not testing the real application but some fake version.
• Raku: It's good that you realize that something is wrong with this approach.
• Fredrik: Well, it depends on what you are checking. At one time I was maintaining a perl script that was depending on some sleep statements. To make it possible to test, I added a flag and if it was set I skipped the sleeps. Same functionality, but when testing I didnt have to wait for 30 seconds. Generally speaking though, dont add flags and use mocks like suggested.

Answer 1

what would be a good way to check the email has been sent?

That is why folks invent mocks.

Start reading about PHP Mock Libraries. For example: http://code.google.com/p/yaymock/.

I'm sure there are a dozen more.

• Ross Patterson: For the record, though, you can spend huge amounts of time keeping your mock setups in sync with changes to the systems they're mocking. But it still beats the heck out of multi-pathing your code for test/prod use.
• S.Lott: "spend huge amounts of time keeping your mock setups in sync with changes to the systems they're mocking" is rare. When it does happen, it's an architecture smell. Something is too volatile and should be replaced with something less volatile. Nothing to do with testing. Or mocks. Everything to do with architecture choices overall. It may be discovered by test fragility.
• GordonM: PHPUnit allows you to create a mock from a real implementation, so mocking shouldn't be that difficult in most cases unless the protocol of your class is in a very unstable state and keeps changing all the time. If that's the case then it's usually a sign that you need to do a bit of design work before actually sitting down to code anything. Mocks are a far better solution than introducing code into your implementation that exists purely for testing and debugging.