feat: add std/expect

[kt3k]

Continued from #3627

This PR adds std/expect mostly compatible with expect of jest.

Remaining:

• toHaveLength
• toHaveProperty
• toContain
• toContainEqual
• Fix toBeCloseTo tolerance handling

Mock related:

• fn (mock)
• toHaveBeenCalled
• toHaveBeenCalledTimes
• toHaveBeenCalledWith
• toHaveBeenLastCalledWith
• toHaveBeenNthCalledWith
• toHaveReturned
• toHaveReturnedTimes
• toHaveReturnedWith
• toHaveLastReturnedWith
• toHaveNthReturnedWith

Testing:

• add test cases

We'd avoid supporting snapshot related APIs for first pass (toMatchSnapshot toMatchInlineSnapshot toThrowErrorMatchingSnapshot toThrowErrorMatchingInlineSnapshot)

Done:

• documentation

closes #3813 1779

[andrewthauer]

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

[iuioiua]

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.

[kt3k]

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.

[andrewthauer]

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

[kt3k]

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

[andrewthauer]

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 😀.

[bartlomieju]

This looks mostly good to me, I'm a bit worried about a number of modules that were added - 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. Could you reconsider adding a single module that has all the matchers inside it?

[bartlomieju]

What's the reason for splitting into so many small modules?

[bartlomieju]

Is there a test that covers this tolerance?

[kt3k]

Oops, this has been already resolved in 357ecb3

[kt3k]

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

[kt3k]

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