Very much looking forward to this. Curious though, would it make sense to put this under std/testing or may std/testing/expect instead?

We thought the expect() implementation, once complete with testing, would be of a sufficient size that it might justify having it as its own sub-module. Plus, it'd be more visible.

Curious though, would it make sense to put this under std/testing or may std/testing/expect instead?

I'm in favor of keeping the implementation in std/expect, but I'm open to the idea of re-exporting this from somewhere in std/testing, such as from std/testing/bdd.ts.

Out of curiosity, is the plan to keep all modules at the top level or will there be any nesting?

I personally think I'd find it more intuitive to scan top level areas first, then drill into them further. For example I'd find testing and then look inside to see bdd and expect, etc.. A possible structure might look like:

└── testing
    ├── bdd
    │   └── mod.ts
    ├── expect
    │   └── mod.ts
    └── mod.ts

We generally prefer top level modules over nested structure. For example, we moved some complex modules from encoding/ to top-level to avoid the nested structure in the past. cf #3123

Right. For encoding that makes sense to me. I personally wouldn't think to look under that initially for json, yaml, etc.

I would say that expect is much less clear to me own its own at the top level then the encoding ones. Putting it under testing would give it context and make it more clear. My 2 cents anyways. I'll will say no more now 😀.

if you're unit testing a file that has no dependencies besides pulling expect/mod.ts then the overhead of loading all these small modules might be non-trivial.

Fair enough. I'll move all matchers into _matchers.ts

Landing this as std/expect for now. Let's revisit std/expect vs std/testing/expect before stabilizing this.