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?
1
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.
3
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.