@theopolis thanks! just to make sure I’m following how you mean “right” - are you agreeing that the test isn’t really intended to constrain what output is there only that the listed values are at least present?

Not constraining to exactly that list of values sounds more reasonable than what currently exists. I am not sure of the original test intention 😛

Well, I believe that there was an intention of checking that the column would contain valid values and that the table was actually working correctly. Without checking values, the table could be showing garbage. That been said, obviously the issues is that the test doesn't adapt to the system it's run on, so the only other two ways I see which give more value to test is to retrieve that information from another "more reputable" source (system commands), accepting it as the "truth" and checking it against the table results. This is the only way to have the test adapt to the system it's run on and test almost the whole pipeline. The other way (but we lack the framework), would've just been to fake what the table is using to extract this information, so that it would receive a controlled set of values that we could later check.

👍 the only other thing I was thinking is that the query could contain the values it wants to see and then validate that they are present in the specificvaluescheck instance. I kind of don’t like that either but I think it would work and give the same confidence level