While learning to develop in PHP it has been easy enough that my short, one page, 20 line little scripts I could add "testing code" directly to my functions to figure out where I am or get close to the area in the code where the issue is found (for example, "print_r($var)," "var_dump($var)," "print 'you are here') type stuff.

Now that my code bases are growing lines and lines deep and accross multiple files, it's becoming a pain to go through and uncomment out all of my test code, and then go back and recomment it out again once an issue is resolved.

Recently I have discovered git in managing my larger applications. I've latched onto branches, and I have a testing branch and production branch I jump between when debugging. The testing branch of course has all my 'print this or that' testing code.

However, this still doesn't feel right.

As code grows, what are ways I can test and debug it? What are best practices for testing and debugging code as applications get larger and more complex? The phrase "Unit testing" catches my eye now and then, but it's still unfamiliar to me. Is this something I should be paying attention more to? Do large projects have different testing and production code bases and is a version control system the correct way to approach managing it?

  • 2
    I think you are looking for term debugging code in the first sentence ( instead of "testing code")
    – mkk
    Apr 22, 2013 at 7:55

2 Answers 2


Yes, you should absolutely be paying attention to unit testing. You should be breaking your code into units (functions, classes), which you can test individually. And you do this by writing code which executes those units with known inputs and tests the return for expected outputs.

"Testing" by inserting print statements is not really testing, it's debugging. And it's a useful debugging technique, but you do not leave those print statements in your code. You should only insert them as needed for a quick test run or two to give you a hint as to what the problem you're debugging is, then you remove them. Of course, with a real debugger hooked up to the code you can debug values without needing to alter the code at all.

You should also get into the habit of logging. You may and should have your code interspersed with log statements of various levels which you can switch on and off as necessary.

Start reading here: http://www.phpunit.de/manual/current/en/automating-tests.html
Then look into remote debugging: http://xdebug.org/docs/remote
And then into logging: https://github.com/Seldaek/monolog

This will probably start you down the road of "how do I break my code into units?", for which you should learn the proper use of functions, followed by classes and objects. And that very quickly gets you into the realm of patterns, endless discussions and proper application architecture.

  • Hmm, this brings up a good question. I didn't know there was a difference between testing and debugging, but that testing should be used to find bugs to remove. But this is not the case? The differences are greater?
    – user658182
    Apr 22, 2013 at 5:35
  • 3
    Testing is asserting that your code works as it should or telling you that it doesn't. Debugging is the activity of finding a bug (discovered during testing) and fixing it.
    – deceze
    Apr 22, 2013 at 5:37
  • Hopefully bugs are found in testing, eh?
    – WarrenT
    Apr 22, 2013 at 22:24

Half of testing is having the right perspective; one way to look at it is that you're using your code as a way to determine if your code is suitable for production. That is, if you're righting a class EmailSanitizer, you write a few test scripts that exercise EmailSanitizer, and if those tests all pass, then that builds confidence that the same code you've written for the tests is production-worthy.

I feel that once you start working from that perspective, you'll soon organically get a good feeling about what is and isn't appropriate to consider when writing test code.

Not the answer you're looking for? Browse other questions tagged or ask your own question.