Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

This question already has an answer here:

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?

share|improve this question

marked as duplicate by gnat, MichaelT, Kilian Foth, Dan Pichelman, GlenH7 Feb 20 at 20:52

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

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

2 Answers 2

up vote 6 down vote accepted

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:
Then look into remote debugging:
And then into logging:

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.

share|improve this answer
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 '13 at 5:35
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 '13 at 5:37
Hopefully bugs are found in testing, eh? – WarrenT Apr 22 '13 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.

share|improve this answer

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