what is the benefit of unit testing over debugging

Hi
if any error or exception happen i debug my code. but what about unit testing ?
does it gives something over debugging? what is it?

thanks in advance.

Unit testing and debugging are two totally different things:

You do unit testing after you have completed your code, to find out any problems it might have.

Once you find out a problem, you debug your code to find the exact reason for the problem and to fix it.

Quote:

---

You do unit testing after you have completed your code, to find out any problems it might have.

---

like what problems?
problems will appear while coding and gives exception. so what problem that i will detect after finish coding?

There are many things.
e.g. Have a look at the following two code blocks that programmers often mess up with.

Code:

---

If a > 0 Then
    'do something
End If

If a >= 0 Then
    'do something
End If

---

This test is called boundary condition test.
You might have mistakenly put a > where >= is required, or vice-versa. This will include/exclude the 0 from the If block wrongly. This would never generate exception, but will give you wrong results at runtime or cause your program to function in a wrong way.

Moreover, your program is never expected to crash in odd conditions. That's what you find in unit testing. Are there any situations where my program will behave abnormally or crash?

e.g. Let's take the same previous example here:

Code:

---

If a > 0 Then
    Result = b / a
End If

If a >= 0 Then
    Result = b / a
End If

---

If you have mistakenly put the >= instead of >, your program will crash when a=0 with a "division by zero" error.

Finding this problem is part of unit testing.
Once the problem is found, you inspect the code to check what is wrong that is causing the problem. That is called debugging.

thanks for reply
what i understand from you is
unit testing is useful in situations that i did not try the input value that cause the exception like divide by zero and of course i will not handle that exception
is it?
what about other testings that done for me like the one you mention above?
is team suite edition of Visual studio.net have unit testing ?
thanks in advance.

Quote:

---

Originally Posted by macnux

unit testing is useful in situations that i did not try the input value that cause the exception like divide by zero and of course i will not handle that exception
is it?

---

Of course you will have to handle the error. Your program should never crash. You should always enclose the suspect code in a try..catch block and handle that exception.
One of the objectives of unit testing is to find such code that can cause problems and needs to be enclosed in try..catch blocks.

Quote:

---

Originally Posted by macnux

what about other testings that done for me like the one you mention above?

---

Unit testing is a form of white box testing. You have access to the code causing problems and can figure out why/where something is going wrong.
Testers usually perform black box testing and might not be able to find out all problems related to your code.

Quote:

---

Originally Posted by macnux

is team suite edition of Visual studio.net have unit testing ?

---

Yes, VSTS has support for unit testing.

Unit testing usually involves a control set (known input values which are expected to output a specific known set of values)... it also usually involves running the object in isolation... a mini app (or a testing module) is used to create the object, input the data and retrieve the outputs and signify a success or failure. It will also involve inputting known bad data - to see what the reactions will be (this is usually to test the error handling).

-tg

Hey,

Unit testing also provides the ability to re-test your code after making some changes, also known as regression testing. Let's say you have completed your code, and ran through your unit tests, but then the client wants something else changed. You can make these changes in the knowledge that you can run the code through the unit tests again to ensure that everything is still operating as you expect it.

Gary

Quote:

---

Originally Posted by Pradeep1210

You do unit testing after you have completed your code, to find out any problems it might have.

---

In the case of test-driven development you actually write the tests first, then write code to make them pass. The idea is that you should decide first what your code is supposed to do, so you can write tests that will only pass if it actually does do that. You then write code to make the test pass, so you know the code does what it is supposed to do.

If you choose not to use test-driven development then you should still write your unit tests in small chunks as you are developing the project rather than leaving them all to the end.

It's also worth noting that, as the name suggests, unit testing is testing of individual units of code, i.e. one or more tests for each individual method. As tg suggested, you try to test that method in isolation. To do this properly really requires defining all your functionality through interfaces and then providing mock implementations. For instance, if ClassA.MethodA calls ClassB.MethodB and that calls ClassC.MethodC, how do you test ClassA.MethodA without a dependency on ClassB and ClassC? The answer is that you make ClassA depend on interface InterfaceB instead of ClassB. ClassA can then call InterfaceB.MethodB. In the real app you would have ClassB implement InterfaceB so that ClassA can use an instance of ClassB, but in testing you'd use a different class that also implemented InterfaceB but provided a well known and very basic implementation and doesn't involve ClassC at all. Likewise you test ClassB using a mock object that implemented InterfaceC. In this way none of your classes actually depend on each other, so you can test each one in isolation. There are numerous free and commercial mocking libraries to help with this type of testing.