Testing: use synctest throughout

[findleyr]

We have several tests that rely on timing, and have been meaning to replace this with uses of synctest. This issue tracks that work.

(see any usage of the time package in test files)

[jba]

Don't we need the module to be on Go 1.24?

Can we bump it now that 1.25 is out?

[findleyr]

@jba we can just move the tests that rely on timing to a build-tagged file.

[La002]

@findleyr Do we maintain two files for moved tests - 124 and 125 like conformance_test? or just 125 like capabilities_test

[maciej-kisiel]

Hi @La002, I have taken over maintenance Go SDK recently and I'm catching up on open issues and PRs. I'll try to review your PR soon.

Re your question: generally, I would say that we shouldn't lose coverage for existing tests which means we should leave existing tests as is with a TODO to remove them when we drop Go 1.24 support and a separate file that compiles only for Go 1.25+.

Note that we currently still support Go 1.23, but I already have a PR to update the requirement to 1.24: #765.

I also took the liberty to assign you to this issue since you already have a PR.

[La002]

Hi @maciej-kisiel,

Got it, thanks for clarifying. I ran into a couple of issues while trying this out:

1. Test name collisions: If we have tests with the same name in both files, we'll get duplication errors. We could rename the new synctest tests with a small variation (e.g., prefix with "Synctest"), but then Go 1.25 users would run the same test twice. Is that okay?

2. Build constraint approach: Alternatively, we could split files with //go:build !go1.25 (old) and //go:build go1.25 (new). But then both files would need to be "complete" with all tests (timing-dependent + non-timing-dependent). This means a lot of duplicate code and double maintenance.

What do you think works better?

[maciej-kisiel]

I would err on the side of easier maintenance. Our tests don't take too much time to run, so it shouldn't hurt if some logic is tested twice for a few months.