Commits on May 23, 2025

1. feat: fail test on trapped but unreleased calls (#15) …

   part of#13Will fail test with an error message if you trap a call and don't release it.I've also added 2 test cases to the unit test.One is a skipped test that you can unskip to see what it looks like if you don't release the trapped call.One tests what happens if two different traps catch the same call. It gets a little awkward because when you `Release()` the call, it waits for the call to complete. One of the main purposes is to ensure that a timer or ticker is set, and if we don't wait for the call to complete, you can't ensure the timer is set before you advance the clock. The awkward consequence is that the `Release()` calls will deadlock if they happen on the same goroutine because _all_ traps have to release the call before it will return.We separate out the trapping of the call and releasing of the call so that you have a chance to manipulate the clock before the call returns. But, actually, there are really 3 phases to a trapped call:1. Call is trapped2. All traps released, we get the time and do the work (e.g. actually setting the timer)3. Call completesAfter `trap.Wait()` returns, we know phase 1 is complete. But, `Release()` actually conflates phase 2 and 3, so there is no way to release the trap without waiting for phase 3.Generally we don't care that much about the distinction, it's really only in the case of multple traps that you'd need to release without waiting to avoid the deadlock.We could make those phases explicit: `trap.Wait().Release().WaitForComplete()`, but that seems pretty involved for what I think is generally an edge case.WDYT?

   

   spikecurtis authoredMay 23, 2025
   Configuration menu

   • View commit details
   • Copy full SHA for d87ad1f
   • Browse repository at this point

   Copy the full SHA

   d87ad1fView commit details

   Browse the repository at this point in the history

2. feat: log clock calls, traps, time advancement (#16) …

   fixes#13Adds logging of traps, calls, and advancing the clock like:```=== CONT  Test_MultipleTraps    mock.go:438: Mock Clock - Trap Now(..., [0])    mock.go:438: Mock Clock - Trap Now(..., [1])    mock.go:200: Mock Clock - Now([0 1]) call, matched 2 traps    mock_test.go:340: Mock Clock - Advance(1s)    mock_test.go:350: Mock Clock - Advance(1s)    mock.go:200: Mock Clock - Now([end]) call, matched 0 traps```This should make it easier to debug a variety of issues, including not setting the trap before the call happens.

   

   spikecurtis authoredMay 23, 2025
   Configuration menu

   • View commit details
   • Copy full SHA for 49f235b
   • Browse repository at this point

   Copy the full SHA

   49f235bView commit details

   Browse the repository at this point in the history

3. !feat: Call.Release takes context; add MustRelease (#17) …

   **BREAKING CHANGE**Adds a `context.Context` to `(*Call.).Release()` and a new `MustRelease()`, since releasing a call can be blocking.  Use like```err := call.Release(ctx)if err != nil {  t.Error(err.Error())}```or more succinctly```call.MustRelease(ctx)```This, combined with a per-test timeout context, should make it much easier to debug issues if you have a call that gets trapped by more than one trap.

   

   spikecurtis authoredMay 23, 2025
   Configuration menu

   • View commit details
   • Copy full SHA for 09f5542
   • Browse repository at this point

   Copy the full SHA

   09f5542View commit details

   Browse the repository at this point in the history