Should I use try catch in my test methods?

Question

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!!

Answer 1

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.

Answer 2

(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.)

Answer 3

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".