Thanks for the links; a lot of interesting material in there.

FWIW, DejaGnu gives some flexibility over how granular the test files can be. For example, here's part of the test case for the -Wmisleading-indentation warning I added in gcc 6: https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/...

i.e. that's one 700 line test source file, expressing most of the test coverage for one feature.

I realize now that the post should have had an example of what such a test case has; see the "dg-warning" directives in that file.

So that's one "single file" test case. That said, I had to put some of the other test cases for that feature into different test files: some of them interact with the preprocessor in "interesting" ways, so it was simplest to split them out.

However, when a test starts failing, it's handy if the failing test is small (especially when stepping through the latter in the debugger...).

So in our testing we have a mix of both big test files covering a lot of material, and small test files, covering very specific corner cases.

Another aspect of granularity is how long the testsuite takes to run: each test source file in the DejaGnu suite involves exec-ing the compiler, which adds a fixed amount of overhead. It parallelizes well, but it's still advantageous to stuff more testing into fewer files (with the obvious tradeoff w.r.t. debugability if something starts failing). This was another reason for adding the unit-testing suite: this part is all done in-process, and so these ~30,000 tests run in less than a second.