cppunit使用命令行参数

Question

I have a CPP unit test which tests a class which is designed to read configuration: we can call this class

Config

The config class has the capacity of doing

Config c;
c.read("/tmp/random-tmp-directory/test.conf");

The random-temp-directory is created by a bash script and should be passed into the test binary.

#!/bin/bash
TEMPDIR=$(mktemp)
cp files/config/test.conf $TEMPDIR/.
./testConfig $(mktemp)/test.conf

The above creates a temp directory, copies our temporary file and passes the path to the test, so it can load the correct file.

Is there a way to tell CPPUNIT to send the commandline arguments, or any arguments to the test registry?

Here is my testConfig.cpp

#include <all the required.h>

CPPUNIT_TEST_SUITE_REGISTRATION(testConfig);

int main(int argc, char ** argv)
{
    CPPUNIT_NS::TestResult testresult;
    CPPUNIT_NS::TestRunner runner;
    CPPUNIT_NS::TestFactoryRegistry &registry = CPPUNIT_NS::TestFactoryRegistry::getRegistry();

    // register listener for collecting the test-results
    CPPUNIT_NS::TestResultCollector collectedresults;
    testresult.addListener(&collectedresults);

    runner.addTest(registry.makeTest());
    runner.run(testresult);

    // Print test in a compiler compatible format.
    CppUnit::CompilerOutputter outputter( &collectedresults, std::cerr );
    outputter.write(); 

    return collectedresults.wasSuccessful() ? 0 : 1;
}

Answer 1

Consider dividing your code into at least three distinct methods: the part that constructs the config file name, the part that reads the config file, and the part that parses what was read from the config file. You can easily and thoroughly unit test both the file name builder and the parser methods. And as long as you can test simply reading data from the file even one time, you should be golden.

[edit]

For example, you might have a method like string & assembleConfigFileName(string basepath, string randompath, string filename) that takes in the different components of your path and filename, and puts them together. One unit test should look like this:

void TestConfig::assembleConfigFileName_good()
{
    string goodBase("/tmp");
    string goodPath("1234");
    string goodName("test.conf");

    string actual(assembleConfigFileName(goodBase, goodPath, goodName));

    string expected("/tmp/1234/test.conf");

    CPPUNIT_ASSERT_EQUAL(expected, actual);
}

Now you can test that you're building the fully qualified config file name exactly correctly. The test is not trying to read a file. The test is not trying to generate a random number. The test is providing an example of exactly what kinds of input the routine needs to take, and stating exactly what the output should look like given that exact input. And it's proving the code does exactly that.

It's not important for this routine to actually read a config file out of a temp directory. It's only important that it generate the right file name.

Similarly, you build a unit test to test for each possible flow through your code, including error scenarios. Let's say you wrote an exception handler that throws if the random path is wrong. Your unit test will test the exception mechanism:

void TestConfig::assembleConfigFileName_null_path()
{
    string goodBase("/tmp");
    string nullPath;
    string goodName("temp.config");

    CPPUNIT_ASSERT_THROW(assembleConfigFileName(goodBase, nullPath, goodName), MissingPathException);
}

The tests are now a document that says exactly how it works, and exactly how it fails. And they prove it every single time you run the tests.

Something you appear to be trying to do is to create a system test, not a unit test. In a unit test, you do NOT want to be passing in randomly pathed config files. You aren't trying to test the external dependencies, that the file system works, that a shell script works, that $TMPDIR works, none of that. You're only trying to test that the logic you've written works.

Testing random files in the operating system is very appropriate for automated system tests, but not for automated unit tests.