views:

88

answers:

4

We have started using the boost unit testing library for a large existing code base, and I have run into some trouble with unit tests incorrectly passing, seemingly due to the reuse of memory on the stack.

Here is my situation:

BOOST_AUTO_TEST_CASE(test_select_base_instantiation_default)  
{
    SelectBase selectBase();
    BOOST_CHECK_EQUAL( selectBase.getSelectType(), false);
    BOOST_CHECK_EQUAL( selectBase.getTypeName(_T(""));
    BOOST_CHECK_EQUAL( selectBase.getEntityType(), -1);
    BOOST_CHECK_EQUAL( selectBase.getDataPos(), -1);
}

BOOST_AUTO_TEST_CASE(test_select_base_instantiation_parameterized)  
{  
    SelectBase selectBase(true, _T("abc"));  
    BOOST_CHECK_EQUAL( selectBase.getSelectType(), false);  
    BOOST_CHECK_EQUAL( selectBase.getTypeName(_T("abc"));
    BOOST_CHECK_EQUAL( selectBase.getEntityType(), -1);
    BOOST_CHECK_EQUAL( selectBase.getDataPos(), -1);
}

The first test passed correctly, initializing all the variables.
The constructor in the second unit test did not correctly set EntityType or DataPosition, but the unit test passed. I was able to get it to fail by placing some variables on the stack in the second test, like so:

BOOST_AUTO_TEST_CASE(test_select_base_instantiation_parameterized)  
{  
    int a, b;
    SelectBase selectBase(true, _T("abc"));  
    BOOST_CHECK_EQUAL( selectBase.getSelectType(), false);  
    BOOST_CHECK_EQUAL( selectBase.getTypeName(_T("abc"));
    BOOST_CHECK_EQUAL( selectBase.getEntityType(), -1);
    BOOST_CHECK_EQUAL( selectBase.getDataPos(), -1);
}

If there is only one int, only the EntityType CHECK_EQUAL fails, but if there are two, both EntityType and DataPos fail, so it seems pretty clear that this is an issue with the variables being created on the same stack memory or some such.

Is there a good way to clear the memory between each unit test, or am I potentially using the library incorrectly or writing bad tests? Any help would be appreciated.

Update:
Select base is a simple class, with only bool, int, and CString member variables. It is a base class to handle state for more complex implementations, so it doesn't access any global variables or global state.

What I need is a way to set the memory between calls to something like 0xdeadf00d, so that if a member variable is left uninitialized the unit test can catch it. Otherwise only the first unit test does any good.

I updated to the boost 1.41, but the issue wasn't resolved. It did affect the issue somewhat in some of the test cases, but not to the point that all the test would fail properly.

+2  A: 

Don't reuse the test case name for different tests.

Instead, call them something like:

test_select_base_instantiation_default_1

test_select_base_instantiation_default_2
bitc
Sorry, that was an anonymization error, the tests won't actually compile if you reuse the test case names. I fixed the post.
Knyphe
+1  A: 

Then there is nothing wrong with the code presented.

It seems you are accessing uninitialized data in SelectBase or any of its dependencies, if it has any. Either you are accessing global state in SelectBase or it instantiates dependencies on its own. Both are discouraged.

bitc
It is true that I am accessing uninitialized data in SelectBase, but that is what I would like the unit test to catch. Perhaps this isn't something that unit testing is capable of, but I don't see why not. All it would take is a good way to set the memory to something generally unexpected (not -1 in this case, but 0 would be likely to cause similar issues in other cases)
Knyphe
Tests can never prove that something is correct. They can only find the problems that you explicitly test. There are endless of possibilities for something else to be faulty. You might want to use design-by-contract in this situation to make sure that each method gets what it needs and produces what is required of it.
bitc
You can also reverse the expectation and only let the test pass if the method fails as expected. That should be applicable here.
bitc
+2  A: 

Try BOOST_TEST_RANDOM if you want ++paranoia.

Rhys Ulerich
But also reverse the expectations should be good as mentioned above.
jpyllman
This does get the tests to fail, but on an inconsistent basis. If I can't figure something else out, this looks like the best bet.
Knyphe
I don't understand how the expectations can be reversed. The expectation is that the object will be properly initialized, and the tests will fail if any member variable is not initialized. I may be misunderstanding, but I don't see how to reverse that.
Knyphe
A: 

I ended up writing a function to set the object to an invalid state after each test case:

void unsetSelectBase(SelectBase selectBase) 
{
    selectBase.setSelectType(true);
    selectBase.getTypeName(_T("InvalidName"));
    selectBase.getEntityType(42);
    selectBase.getDataPos(2718);
}

BOOST_AUTO_TEST_CASE(test_select_base_instantiation_default)  
{
    SelectBase selectBase();
    BOOST_CHECK_EQUAL( selectBase.getSelectType(), false);
    BOOST_CHECK_EQUAL( selectBase.getTypeName(_T(""));
    BOOST_CHECK_EQUAL( selectBase.getEntityType(), -1);
    BOOST_CHECK_EQUAL( selectBase.getDataPos(), -1);
    unsetSelectBase(selectBase);
}


BOOST_AUTO_TEST_CASE(test_select_base_instantiation_parameterized)  
{  
    SelectBase selectBase(true, _T("abc"));  
    BOOST_CHECK_EQUAL( selectBase.getSelectType(), false);  
    BOOST_CHECK_EQUAL( selectBase.getTypeName(_T("abc"));
    BOOST_CHECK_EQUAL( selectBase.getEntityType(), -1);
    BOOST_CHECK_EQUAL( selectBase.getDataPos(), -1);
    unsetSelectBase(selectBase);
}

This causes all the test cases to fail appropriately when any member variables are not initialized. I guess this is just another manual setup/tear down type task that is necessary, since the framework doesn't clear the memory.

Knyphe