We've built up a substantial number of unit tests for our main program over the years. Several thousand. The problem is that we don't have a clear idea of what tests we have because there are so many. And that's a problem because we don't know where we're weak on tests (or where we have duplicates).
Our app is a reporting engine. So you can have a template that is used to test parsing (do we read all table properties), merging in data (did we keep the correct table properties in the merge), formatting the final page (is the table placed correctly on the page), and/or the output format (is the created DOCX file correct).
Add to this what we need to test. Take the padding around a table cell (we use Word, Excel, & PowerPoint for the report design). We have to test the padding across page break, for a table inside a cell, vertically merged cells, horizontally merged cells, a vertically & horizontally merged cell that contains a table with a vertically & horizontally merged cells in the inner table, where that table breaks across a page.
So what category does that test go in? Table padding, page breaks, nested cells, vertically merged cells, horizontall merged cells, or something else?
And how do we document these categories, name the unit tests, etc.?
Update: A number of people have suggested using coverage tools to verify that we have full coverage. Unfortunately that is of limited use in our case because the bugs tend to be due to specific combinations so it's code that has all been tested, but not in that combination.
For example, we had a customer yesterday that started a Word bookmark at the end of a forEach loop in their template (a Word document) and ended it in the beginning of the next forEach loop. This all used code that has unit tests against it, but we had not thought of the combination of a template expanding a bookmark start to be started 25 times, then ended 10 times (the two forEach loops had a different number of rows).
Best Answer
Generally, I tend to mirror the source tree for my unit tests. So, if I had src/lib/fubar, I would have a test/lib/fubar which would contains the unit tests for fubar.
However, what you seem to be describing are more functional tests. In that case, I would have a multi-dimensional table that enumerated all your possible conditions. Then, the ones that have no tests are either nonsensical or need a new test. You can, of course, then put them in sets of test suites.