> -----Original Message-----
> From: Kees Cook
>
> On Fri, Mar 13, 2020 at 05:54:57PM -0700, Jakub Kicinski wrote:
> > Note that we loose a little bit of type safety
> > without passing parameters as an explicit argument.
> > If user puts the name of the wrong fixture as argument
> > to CURRENT_FIXTURE() it will happily cast the type.
>
> This got me to take a much closer look at things. I really didn't like
> needing to repeat the fixture name in CURRENT_FIXTURE() calls, and then
> started coming to all the same conclusions you did in your v1, that I
> just didn't quite see yet in my first review. :P
>
> Apologies for my wishy-washy-ness on this, but here's me talking myself
> out of my earlier criticisms:
>
> - "I want tests to be run in declaration order" In v1, this is actually
> mostly retained: they're still in declaration order, but they're
> grouped by fixture (which are run in declaration order). That, I think,
> is totally fine. Someone writing code that interleaves between fixtures
> is madness, and having the report retain that ordering seems awful. I
> had thought the declaration ordering was entirely removed, but I see on
> closer inspection that's not true.
>
> - "I'd like everything attached to _metadata" This results in the
> type unsafety you call out here. And I stared at your v2 trying to
> find a way around it, but to get the type attached, it has to be
> part of the __TEST_F_IMPL() glue, and that means passing it along
> side "self", which means plumbing it as a function argument
> everywhere.
>
> So, again, sorry for asking to iterate on v1 instead of v2, though the
> v2 _really_ helped me see the problems better. ;)
>
> Something I'd like for v3: instead of "parameters" can we call it
> "instances"? It provides a way to run separate instances of the same
> fixtures. Those instances have parameters (i.e. struct fields), so I'd
> prefer the "instance" naming.
Could I humbly suggest "variant" as a possible name here?
IMHO "instance" carries along some semantics related to object
oriented programming, which I think is a bit confusing. (Maybe that's
intentional though, and you prefer that?)
BTW - Fuego has a similar feature for naming a collection of test
parameters with specific values (if I understand this proposed
feature correctly). Fuego's feature was named a long time ago
(incorrectly, I think) and it continues to bug me to this day.
It was named 'specs', and after giving it considerable thought
I've been meaning to change it to 'variants'.
Just a suggestion for consideration. The fact that Fuego got this
wrong is what motivates my suggestion today. You have to live
with this kind of stuff a long time. :-)
We ran into some issues in Fuego with this concept, that motivate
the comments below. I'll use your 'instance' terminology in my comments
although the terminology is different in Fuego.
>
> Also a change in reporting:
>
> struct __fixture_params_metadata no_param = { .name = "", };
>
> Let's make ".name = NULL" here, and then we can detect instantiation:
>
> printf("[ RUN ] %s%s%s.%s\n", f->name, p->name ? "." : "",
> p->name ?: "", t->name);
>
> That'll give us single-instance fixtures an unchanged name:
>
> fixture.test1
> fixture.test2
We ended up in Fuego adding a 'default' instance name for
all tests. That way, all the parsers don't have to be coded to distinguish
if the test identifier includes an instance name or not, which turns
out to be a tough problem.
So single-instance tests would be:
fixture.default.test1
fixture.default.test2
>
> and instanced fixtures will be:
>
> fixture.wayA.test1
> fixture.wayA.test2
> fixture.wayB.test1
> fixture.wayB.test2
>
Parsing of the test identifiers starts to become a thorny issue
as you get longer and longer sequences of test-name parts
(test suite, test fixture, sub-test, test-case, measurement, instance, etc.)
It becomes considerably more difficult if you have more than
one optional element in the identifier, so it's useful to
avoid any optional element you can.
>
> And finally, since we're in the land of endless macros, I think it
> could be possible to make a macro to generate the __register_foo()
> routine bodies. By the end of the series there are three nearly identical
> functions in the harness for __register_test(), __register_fixture(), and
> __register_fixture_instance(). Something like this as an earlier patch to
> refactor the __register_test() that can be used by the latter two in their
> patches (and counting will likely need to be refactored earlier too):
>
> #define __LIST_APPEND(head, item) \
> { \
> /* Circular linked list where only prev is circular. */ \
> if (head == NULL) { \
> head = item; \
> item->next = NULL; \
> item->prev = item; \
> return; \
> } \
> if (__constructor_order == _CONSTRUCTOR_ORDER_FORWARD) {\
> item->next = NULL; \
> item->prev = head->prev; \
> item->prev->next = item; \
> head->prev = item; \
> } else { \
> p->next = head; \
> p->next->prev = item; \
> p->prev = item; \
> head = item; \
> } \
> }
>
> Which should let it be used, ultimately, as:
>
> static inline void __register_test(struct __test_metadata *t)
> __LIST_APPEND(__test_list, t)
>
> static inline void __register_fixture(struct __fixture_metadata *f)
> __LIST_APPEND(__fixture_list, f)
>
> static inline void
> __register_fixture_instance(struct __fixture_metadata *f,
> struct __fixture_instance_metadata *p)
> __LIST_APPEND(f->instances, p)
With my suggestion of 'variant', this would change to:
static inline void
__register_fixture_variant(struct __fixture_metadata *f,
struct __fixture_variant_metadata *p)
__LIST_APPEND(f->variants, p)
Just my 2 cents.
-- Tim
