StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>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.</p> <p>[edit]</p> <p>For example, you might have a method like <code>string & assembleConfigFileName(string basepath, string randompath, string filename)</code> that takes in the different components of your path and filename, and puts them together. One unit test should look like this:</p> <pre><code>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); } </code></pre> <p>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.</p> <p>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.</p> <p>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:</p> <pre><code>void TestConfig::assembleConfigFileName_null_path() { string goodBase("/tmp"); string nullPath; string goodName("temp.config"); CPPUNIT_ASSERT_THROW(assembleConfigFileName(goodBase, nullPath, goodName), MissingPathException); } </code></pre> <p>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.</p> <p>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.</p> <p>Testing random files in the operating system is very appropriate for automated system tests, but not for automated unit tests.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload