Support ambiguous property types on mocked interfaces

[notanengineercom]

Fixes #178

This allows mocking callable interfaces. See details in the linked issue.
This also solves a known issue where ambiguous property types of an interface couldn't be asserted (a property that can called as a method and a property).
The implementation is not ideal, but it works and avoids suppressing a valid expectation.
By deferring the exception we can cover this case as well, with the drawback that it escapes the context scope and bubbles up to the main context, resulting in a uncaughtException.
E.g

interface Library {
  subSection: AmbiguousSection
}

interface AmbiguousSection {
  (): string
  subMethod: () => string
}


const lib = Substitute.for<Library>()
lib.subSection().returns('subSection as method')
lib.subSection.returns({ subMethod: () => 'subSection as property' } as AmbiguousSection)

lib.subSection()
lib.subSection()
lib.subSection.subMethod()

// Assertion logic before
lib.received(2).subSection() // This would fail with a Call count mismatch exception, because when executing the assertion, the proxy can't know if we are referring to a property or a method.
// The proxy would run like:
// 1. I'm in a assertion, waiting to see what property is called
// 2. I received subSection, let me run the assertion
// 3. The assertion finds that there have been 1 property call to lib.subSection, but the assertion expects 2
// 4. It throws SubstituteException with the due to a call count mismatch

// Assertion logic now
lib.received(2).subSection() // This would succeed because of the deferred exception.
// The proxy would run like:
// 1. I'm in a assertion, waiting to see what property is called
// 2. I received subSection, let me run the assertion
// 3. The assertion finds that there has been 1 property call to lib.subSection, the assertion expects 2 but there has been also method calls to lib.subSection. Schedule the call count mismatch exception.
// 4. I'm getting a method call to myself (subSection). Let me run the assertion
// 5. The assertion cancels the scheduled exception. It finds that there have been 2 method calls to lib.subSection and the assertion expects 2. The assertion ends

[ffMathy]

Very interesting! 😍 Feel free to merge when you feel like it's ready.

[notanengineercom]

I'm aware of the failing test - currently trying to think how to solve it.
The main issue is, that the assertion context doesn't know yet if the object member to assert is a method or a property :/

[notanengineercom]

I added a folder to verify and test the compatibility with different test runners. I wanted to make sure that the new uncaught exception gets reported correctly in different test runners - I added checks for the most popular ones.
This is how it would look like:

Ava

Jest

Mocha

Node.js

Vitest

@ffMathy

[notanengineercom]

This is the test output inside the compatibility-checks folder

npm test               

> [email protected] test
> node --require tsx/cjs --test test/**

▶ Verifies test runner compatibility
  ▶ ava
    ✔ reports the uncaught Substitute exception (963.726083ms)
  ▶ ava (964.909625ms)

  ▶ jest
    ✔ reports the uncaught Substitute exception (1994.183541ms)
  ▶ jest (1994.437125ms)

  ▶ mocha
    ✔ reports the uncaught Substitute exception (476.041541ms)
  ▶ mocha (476.190667ms)

  ▶ nodejs
    ✔ reports the uncaught Substitute exception (419.588625ms)
  ▶ nodejs (419.755291ms)

  ▶ vitest
    ✔ reports the uncaught Substitute exception (811.546333ms)
  ▶ vitest (811.702708ms)

▶ Verifies test runner compatibility (4667.739583ms)

ℹ tests 5
ℹ suites 6
ℹ pass 5
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 4740.15625

[ffMathy]

Another great PR! I think I'll have mine ready soon too, and then we can ship v2.0! 😍