Decide a better (or review the current one) approach for test.id

[beraldoleal]

Today we have a TestID() class that was very well discussed in the past and has its own heuristic to create a consistent test.id.

With the introduction of TestSuites() we need to identify the test by the suite which belongs also to avoid collisions. So we are pre-pending, the suite.name on HumanOutput when we have multiple Test Suites.

We should make this as clear as possible for our users and contributors, and probably we need a clear separation of what is a nice "machine-readable id" vs "human-readable id".

Besides that, because have a specific class for ids (TestID), today we have multiple calls to this class with different arguments, spread around the code, what makes consistency, and debug a little difficult.

The goal here is to discuss a possible code move and improvements here.

One possible scenario would be to have test/tasks with those properties:

task/test.id = Machine Readable id (Hash for instance)
task/test.name = User custom name
task/test.path = Actual fs path where is the test

Also, we could think about the advantages of not having the TestID() class anymore, of course, test.id (or a different property) would give us something generated by the same code found today inside TestID.

PS: Just taking this note here to not forget, but we can discuss this after LTS, no worries.

[pevogam]

Thanks for the write-up!

task/test.id = Machine Readable id (Hash for instance)
task/test.name = User custom name

I thinks this is optimal but let's see what the others say in the future.

task/test.path = Actual fs path where is the test

I would drop this because it adds the assumption that each test should be associated with a file and a path in particular which is not the case for many varianter-generated tests.

Also, we could think about the advantages of not having the TestID() class anymore, of course, test.id (or a different property) would give us something generated by the same code found today inside TestID.

This also sounds very good.