I started this thread because I will probably have a lot of questions. I've never really written a lot of unit tests so bare with me please. I wrote this command line application to filter out unwanted debug messages in a debug spew. What the application does isn't that important at this point, it is written in C++. I'm writing unit tests for this application too using Boost::test. Again that isn't too important at this point. My questions are mainly about testing the command line entries by the operator. The general format of the command with some examples.

Filter -i InputFile -o OutputFile -t FilterType
or
Filter InputFile -o OutputFile -t FilterType
or
Filter InputFile -o OutpFile --TypeFilter FilterType
or for getting help on using the command
Filter -h
Filter --help

The command arguments can be in any order the only required argument is the input file as with no other parameters the application uses defaults.

So you can see hopefully there are a lot of different ways to order the arguments as well as specifying the arguments on the command line.

Finally my questions on this. I could write a Unit test for each combination of command line arguments. In other words I could write a test to see that the command line is parsed correctly for instance:
Filter -o OutputFile -t FilterType InputFile

Another test for
Filter -o OutputFile InputFile -t FilterType

Or I could combine this into one test indicating that it tests the ordering of the arguments basically. I guess it probably makes the most sense to combine tests in a way that indicates a certain functionality is test. I can also see advantages to having a lot of separate tests. Anyway wondering how people more experienced with unit testing approach this kind of problem. Hopefully I've explained it well enough.

This might not be what you want to hear but my view is you should use a library for parsing the command line arguments (getopt? Maybe there is something better or a C++ solution), and use unit tests to test the smallest piece of functionality that you are responsible for.

So if getopt is meant to give the same result for "Filter -o OutputFile -t FilterType InputFile" as for "Filter -o OutputFile InputFile -t FilterType", you don't need to unit test that, you just test that your program behaves as expected when all these arguments are supplied.

I actually do use a library to parse the command line (boost program_options). Still what the operator selects has to be handled correctly. For instance, say the operator specifies an output file where the parent path does not exist. The library parses the output file selection properly and returns what the operator entered. However, what the operator entered needs to be handled correctly. I would think that a unit testing should test that. For example, if the operator enters an invalid path my application should detect when that is the case and inform the operator. A unit test can be written to test that functionality.

Also, applications can interface to libraries incorrectly, mistakenly and those interfaces should be unit tested as well. Parsing the command line isn't really the thing that needs to be tested here and I probably did a poor job of explaining that. What needs to be tested (at least to start) is processing the operator inputs correctly.

You might consider just writing this unit test as a script that just calls your filter application.

Using C++ to call and then parse the output of filter seems like a minor headache. Maybe consider a python or another scripting language to call filter with some combinations or arguments and parse.