Tree view for -l?

[rr-]

It would be nice to have some mechanism to reflect the filesystem hierarchy in the structure of tests.

The purpose is to:

• Present the project structure in the test list using an attractive tree view - for example:

  util/
      pack/
          zlib
              - Compressing works
              - Decompressing works
          lzss
              - Compressing works
              - Decompressing works
              - Unaligned streams are filled with 0
  

• Simplify searching for things responsible for test failures by having 1:1 test↔class relation

• Establish simple and clear convention for test naming that also solves naming conflicts

• Ability to intuitively search for tests without knowing them, for example after working on dir/subdir/important.cc, relevant tests can be discovered and executed by supplying dir/subdir/ or dir*subdir* as argument

Problems with using existing means to accomplish this:

1. Tags
   • Can't present project structure nicely in the --list
   • Cumbersone to tell directories with the same name ([dir][subdir])
   • Tags in -l are printed in order reverse to the declaration order, so instead of [dir][subdir], it shows [subdir][dir]
2. Test names
   • Cumbersome conflict avoidance, for example to search for tests containing file when one has file/ directory, one needs to look for */*file* or similar (that can fail as well)
   • Doesn't look pretty in -l, can't easily tell typos like one can with -t
   • Feels wrong - we specify two things in one place

So what else? Rather than supplying third option to TEST_CASE() macro, I'm thinking of having special tag syntax such as [/path] that should stay backwards compatible with 99.9% of people out there - and the --list format could change only if there are any path-like tags in the project.
Or much simpler - remember __FILE__ and use it for presentation (-l or new switch) and searches.

[philsquared]

@rr - sorry I missed this the first time around.
Is this still relevant to you?
One thing that has changed in the meantime that is relevant is the -# option, which results in every test case being given an additional tag derived from the filename (i.e. picked out of __FILE__).
It's not quite what you're after because only the filename is considered, not the path - but it might be a step closer to what you wanted.

Personally I'm not sure doing more than this is worth it. If you need an organisational unit beyond filename I think tags are going to be sufficient.

What's still missing is the hierarchical listing aspect. I'm not sure how valuable this is in the general case. But if you're still interested we can talk more about that.

[horenmar]

Once #1190 is in, this can be done by using custom reporter to route -l through.