Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am doing unit testing.

I am trying to test one function.

I call it from my test component. But If remote function cannot handle the exception then my tester component will also get exception, I guess.

So should I worry about getting exception in my tester component?

Thanks.

EDIT:

PS:

Throwing an error is good, but only for other functions, not to end users until its a last option!

OMG I wrote a programming quote!!

share|improve this question
    
I am new to testing, and should I only test the behavior of the function. I think it is called blackbox and whitebox testing. Oh I remember that. I studied that in college! –  Vikas Aug 18 '11 at 6:07
    
What language and xUnit framework are you using specifically? I would argue yes in some cases. –  Greg K Aug 20 '11 at 8:32
    
I am using MXUnit with MockBox and ColdBox for ColdFusion language. –  Vikas Aug 20 '11 at 9:35
add comment

3 Answers

up vote 12 down vote accepted

Short answer: NO.

Don't catch exceptions in unit tests. You are unit testing to find errors and situations where exceptions are raised.

The unit test framework should handle exceptions in a sane manner. Most (if not all) xUnit frameworks have a construct to expect certain exceptions which you use when you want to induce a particular exception condition in the system under test and have a test pass if the expected exception is raised but fail if it does not.

share|improve this answer
    
I think advanced testing framework can handle exception very well, even I find that in Visual studio we can test against exceptions like you said "expected exception". So its good to know and sharing. Thanks.. –  Vikas Aug 18 '11 at 8:43
    
Sometimetime, you want to check if an Exception is thrown, because good testing don't test only cases were things works, but also cases when they fail. –  deadalnix Aug 18 '11 at 9:05
    
You DO want to catch exceptions, as you DO want to test the situations in which exceptions happen (especially your own exceptions). If you write code that's designed to fail with an exception under certain conditions, those conditions should be a part of your test suite, and thus should be tested. Under those tests, those exceptions should be caught and analysed. –  jwenting Sep 7 '11 at 11:04
    
@Jwenting Read the second paragraph - Unit testing frameworks catch the exceptions and allow tests to pass if certain exceptions are raised and fail if they are not –  mcottle Sep 7 '11 at 15:33
add comment

(In contrast to mcottle's answer) Long answer: NO... most of the time

When you say that you expect a test to raise a particular exception, you will know when ANY line in that test raises that particular exception.

That's not quite the same thing as knowing that the method under test throws the exception.

If your test involves setting up an object or context (within the test, not within your framework's version of SetUp), you might be better off wrapping the single line you actually want to test in a try/catch, possibly with a helper.

For instance,

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

and then

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

If this test fails, I know that my method under test threw the exception, and not something in the random setup stuff.

(You should try and avoid random setup stuff. Sometimes, it's easier to have some setup code in the test.)

share|improve this answer
    
Good example! I try to be very careful about limiting the "test" phase to just the precise test, but I'll remember this trick for when I just can't figure out a way to pull that off (e.g., when testing for a race condition and need 'setup' close to the 'test' to hit the condition). –  Ethel Evans Aug 24 '11 at 18:14
add comment

In general, you should just let the exception out, and the testing framework will give you a nice report with all the information you need.


But in the TDD methodology, we are expected to follow that steps:

  1. Write a test
  2. Watch it fail, and make the error understandable
  3. Correct the code
  4. Refactor the code and the test

When you let an exception out, if the error is clear, then it is fine. But sometimes the exception is obscure, or even misguiding. How could you let that be in your code (for you later when you will have forgotten, or for a team member that will loose big time figuring out the problem) ? So my policy is: "If it is necessary to make a failure clear, you need to catch the exception".

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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