Thread: Creating C/C++ Unit Test Cases

Hi guys,

I am trying to create a bunch of unit test cases for my program to get some good code coverage number. Let's suppose that the following is the code that I want to test against.

Code:

class A
{
public:
    ...
    HRESULT func()
    ...
}

HRESULT A::func()
{
    HRESULT hr = S_OK;
    ...
    hr = SomeFunction(...);
    if(FAILED(hr))
    {
        Log(L"some log message")
        ...Do some cleanups before exiting the function...
        goto Exit;
    }
    ...
Exit:
    return hr;
}

For those of you who have experience with unit testing, when you test the class A, would you intentionally make the "SomeFunction(...)" fail (if possible) so that your unit test case would cover(test) even the error-handling codes inside of the if(FAILED(hr)) block? I am trying to figure out where should I draw the line between the things I need to test and things that I don't need to test. Thanks!

First, about testing the error condition:

I do, most probably do, but there is a limit.

You have a log there, and sometimes applications have a robust means of documenting errors of various severity, which are themselves probably tested in isolation to make certain the log system works. If that's the primary thing the error condition does, log and exit, then if you know the log system is stable, it's hardly important to test it.


Now more generally:

I know this could degrade into the merits of goto, and so far as I can tell a great majority of C++ developers (even a majority of C developers) actively refuse to use it. I'm one of them. The brackets following an "if" statement imply a jump in the assembler, and jumps are a basic part of extremely low level structure (like assembler), but in 28 years I've not found a reason to use goto.

In your case, return hr is the same thing. There are arguments to be made that the goto might be a bad idea in the future - what if you only want to perform return hr, but at some point later, as a result of 'normal' processing, need to add statements between exit: and the return?

This example raises another point, though - what is the nature of the error condition? If it's something along the lines of a file not opening, it's debatable as to whether or not that qualifies as an exception. If a file is to be opened and it's reasonable to expect it might not exist, I don't think it does. On the other hand, if the file to be opened is configuration data that was placed as part of installation, it is expected to be accessible, it's absence would be a serious problem, and perhaps that qualifies it for exception handling. In other words, what is the nature of this kind of error, and what is meant by clean up?

In C++, clean up should really be as simple as letting objects fall out of scope, for the most part. In that way, exception handling is well supported, error conditions that are not exceptions are also well covered, and there's less to go wrong.

The reason I went through THAT tributary is this: If I use exceptions, and especially if I write a handler that can recover and continue execution (as opposed to giving up and aborting), I especially want to test those for reliability. That is, if I dare to think I can recover from an error, I want to be certain I perform as if a promise to the user. Think, for example, saving contents they've worked on up to the point of a serious failure, so they don't loose valuable time.