RFC: Inline tests and nested test modules via module blocks

[caspervonb]

Note: early very rough draft, most properties are missing from the interface.
This would be one or two years into the future and most likely an additive feature to declarative tests (#11235).

Our unit of testing are modules, the test runner runs each module in isolation and already offers a shared scope via the top level module scope.

We have before and after hooks via the module's evaluation phase for top level await and we also have lifecycle events in the form of load and unload.

People are asking for a way to group tests into smaller scopes with its own lifecycle hooks, the answer to that today is to for you to create another module but having to create a module for each logical local block isn't that great.

The module blocks proposal (which is currently in stage 2) makes this declarative and we can extend the test harness to embrace module blocks.

Interface

interface TestSpecification {
  name: string,
  // TBD what the actual runtime type is (and name for that matter).
  // See https://github.com/tc39/proposal-js-module-blocks
  mod: string | Module;
  ignore: boolean,
  permissions?: TestPermissions;
  // The rest of the options would probably be here and used as the defaults within this scope.
}

declare namespace Deno {
  export function test(test: TestSpecification);
  export function test(name: string, module: string | Module);
}

Example

export function hello() {}

Deno.test("mod.ts", module {
  import { hello } from "./mod.ts";
  
  console.log("inline test module evaluated");
  
  addEventListener('load', () => {
    console.log("load event dispatched");
  });
 
  addEventListener('unload', () => {
    console.log("unload event dispatched");
  });

  Deno.test("hello", function() {
    hello();
  });
  
  Deno.test("inner", module {
    addEventListener('load', () => {
      console.log("inner load event dispatched");
    });
    
    addEventListener('unload', () => {
      console.log("inner unload event dispatched");
    });

    Deno.test("case", function() {});
  });
});

Life cycle visualised:

$ deno test mod.ts
Check file://example/mod.ts
inline test module evaluated
load event dispatched
test mod#hello ... ok (3ms)
inner load event dispatched
test mod#inner#case ... ok (1ms)
inner unload event dispatched
unload event dispatched

[dsherret]

This is an interesting idea. There are two major disadvantages to this that I believe are dealbreakers though:

1. No way to dynamically generate test cases. Can only be static from my understanding.
2. Within the module block you can't reference declarations outside the module's scope https://github.com/tc39/proposal-js-module-blocks#can-you-close-over-variables-can-you-reference-values-outside-the-module-block

[caspervonb]

No way to dynamically generate test cases. Can only be static from my understanding.

Neat little thing is that you can actually generate modules by creating blob url objects.

Within the module block you can't reference declarations outside the module's scope https://github.com/tc39/proposal-js-module-blocks#can-you-close-over-variables-can-you-reference-values-outside-the-module-block

Yeah it's just inlining a module.