Larry Wall wrote:

  module MyTests {
   sub group1 {
     ok foo :name<test_foo>; ## Q - would a label be better?

>>   ## Elsewhere
>>   MyTests.group1.test_foo is also broken<rakudo>;

I guess I don't see offhand what you're trying to do with that.
We must keep a clean
separation between code that proves success and any indicator that says
"don't try this yet".

That was the intent. The test (within the MyTests module) would define tests in a platfom agnostic way. The "is also" clause would be added in some other place (a platform-specific file) that says which tests are currently broken (or perhaps adds some other tag that indicates that it should be skipped for smoke testing, but not for full regressions).

The point is to have a mechanism within the language (i.e. not a preprocessor) that imposes that tags from afar: a useful action-at-a-distance that is necessary to separate the test from it's current status.

I could also imagine writing code that reads from an Sqlite database, and imposes that info onto the test. Whatever mechanism is used, I think we need a language-defined mechanism to supply a stable unique identifier for each test, so that it can be individually tracked and manipulated. Perhaps "is only" is the wrong way to implement the action-at-a-distance, but it does seem better (IMO) than a preprocessor.

Reply via email to