When to use debug vs unit tests?

I'am a little bit confused what is better to use debug or write unit test? and is this general or there are cases where debug better than unit test?or should I use both of them?

Than开发者_JAVA百科ks

Debugging will help you diagnose non-working code.

Unit tests provide the following:

1. a repeatable means of determining that your code works, both for common scenarios and for edge cases. They will allow you to refactor your code with confidence that it still works.
2. a demonstrable specification of the code. In the absence of a written specification your unit tests are your code's specification. This is particularly true in the Agile world.
3. an aid to building well-structured code. Because you want to run unit tests standalone, you have to write your classes under test to accept different (sometimes mocked) datasources, sinks etc. By encouraging these abstractions and separation of concerns, your code will become well-structured (you can, of course, write well-structured code without unit tests)

Your unit tests should be run repeatedly (most often as part of your build process). If you do break them (most often due to a programming error), then it's time to break out the debugger to identify the issues and fix up the code (or perhaps amend the test) accordingly.

Unit test is used to ensure that code works as expected. Debug is used when you need to find why the code doesn't work as expected.

If you're able to reproduce the bug in unit-test, use a unit-test. It'll last after the bug is solved and "protect" the code in the future against it.

If you have hard time to find the piece of offending code, then debugging is probably a better solution. But, the moment you know where the problem - write a test, make sure it fails and then fix the bug.

Debugging takes more time and it's a "one time" solution. When you have the option to unit-test, prefer a unit-test.

Debugging and writing unit tests are two different things. In theory your development should be driven by unit tests covering the different scenarios. You could debug when you realize that something is wrong with your code and try to see the values of different variables in runtime, etc ... So basically you could debug only when something's wrong.

Another perspective:

Always do unit tests of everything that you can do. The ideal is test each component in isolation then do integration tests of components collaborating.

What you are talking about is a different question though: if something breaks, what should you do, go try and write a unit test or run the debugger. These are not really the choices. If something breaks and you can see the behavior in a unit test, that's ideal. But you still have to find the reason for the behavior. Now your choices are between adding logging and running the debugger, and I vote with the people who say use logging until you can't. The debugger time adds no long-term value to the code. The logging does.

I think this question can be looked at in a deeper manner than some of the answers suggest... though might be a better fit for the programming stack exchange.

First some comments on how debugging and unit testing interact

• Unit testing first can prevent debugging

• When something is sufficiently hard to debug one approach is to stop debugging your problem and start unit testing related things using similar types of of problematic input. You might like to try to simplify the input that causes problems first (assuming your system is determinisitic!)

• Similar to the above point above you might trace your problematic code through the system and start unittesting things lower down the call chain with identical input

Unit testing can be considered as "debugging ahead of time" or "pessimistic debugging", assuming you are going to have a bug so tryin to debug it straight away. If you are doing this when you have an actual problem in mind, it's more like guessing that there is a bug in a particular section of code and that you can elicit it by guessing at broken input.