chore(deps): update tunit to 1.39.0

[thomhurst]

This PR contains the following updates:

Package	Type	Update	Change
TUnit	nuget	minor	1.37.36 → 1.39.0
TUnit.AspNetCore	nuget	minor	1.37.36 → 1.39.0
TUnit.Assertions	nuget	minor	1.37.36 → 1.39.0
TUnit.Assertions.FSharp	nuget	minor	1.37.36 → 1.39.0
TUnit.Core	nuget	minor	1.37.36 → 1.39.0
TUnit.Engine	nuget	minor	1.37.36 → 1.39.0
TUnit.Playwright	nuget	minor	1.37.36 → 1.39.0

---

Release Notes

thomhurst/TUnit (TUnit)

v1.39.0: 1.39.0

What's Changed

Other Changes

• perf(mocks): shrink MethodSetup + cache stateless matchers by @​thomhurst in #​5669
• fix(mocks): handle base classes with explicit interface impls (#​5673) by @​thomhurst in #​5674
• fix(mocks): implement indexer in generated mock (#​5676) by @​thomhurst in #​5683
• fix(mocks): disambiguate IEquatable.Equals from object.Equals (#​5675) by @​thomhurst in #​5680
• fix(mocks): escape C# keyword identifiers at all emit sites (#​5679) by @​thomhurst in #​5684
• fix(mocks): emit [SetsRequiredMembers] on generated mock ctor (#​5678) by @​thomhurst in #​5682
• fix(mocks): skip MockBridge for class targets with static-abstract interfaces (#​5677) by @​thomhurst in #​5681
• chore(mocks): regenerate source generator snapshots by @​thomhurst in #​5691
• perf(engine): collapse async state-machine layers on hot test path (#​5687) by @​thomhurst in #​5690
• perf(engine): reduce lock contention in scheduling and hook caches (#​5686) by @​thomhurst in #​5693
• fix(assertions): prevent implicit-to-string op from NREing on null (#​5692) by @​thomhurst in #​5696
• perf(engine/core): reduce per-test allocations (#​5688) by @​thomhurst in #​5694
• perf(engine): reduce message-bus contention on test start (#​5685) by @​thomhurst in #​5695

Dependencies

• chore(deps): update tunit to 1.37.36 by @​thomhurst in #​5667
• chore(deps): update verify to 31.16.2 by @​thomhurst in #​5699

Full Changelog: v1.37.36...v1.39.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Code Review: chore(deps): update tunit to 1.39.0

This is a straightforward Renovate-generated dependency bump PR. The changes are mechanical — 13 additions, 13 deletions, all version strings — so the review focuses on correctness, consistency, and structural observations.

What the PR Does

Updates TUnit package references from 1.37.36 to 1.39.0 across:

• Directory.Packages.props (central package management for the main solution)
• Five template project files under TUnit.Templates/content/

Correctness: All Good

The version bump itself is correct. v1.39.0 is a real, published release on NuGet and GitHub (verified), and the 13 changed lines are internally consistent — no partial updates or missed files among the packages Renovate manages.

Observation: Intentional Exclusion of TUnit.Aspire Templates

The Aspire template projects (TUnit.Aspire.Test/ExampleNamespace.csproj and TUnit.Aspire.Starter/ExampleNamespace.TestProject/...) still reference TUnit.Aspire at 1.14.0 while TUnit.Aspire is now at 1.39.0 on NuGet. This is not a bug in this PR — TUnit.Templates/content/Directory.Build.props contains a comment explaining the design:

"During solution builds, swap TUnit.Aspire NuGet package for local project reference (TUnit.Aspire is not yet published to NuGet). This file is excluded from the template package."

The Directory.Build.props then conditionally removes the PackageReference and substitutes a ProjectReference to the local TUnit.Aspire project. So the pinned 1.14.0 in those files is a placeholder that is never actually resolved during development builds. However, it will be resolved when end users install the template from NuGet — meaning users would get TUnit.Aspire@1.14.0 instead of 1.39.0. This stale version is a pre-existing concern and is out of scope for this PR, but worth flagging as a separate issue.

Observation: Version Pinning Inconsistency Across Templates

There is an existing inconsistency in how templates pin versions:

Template	Strategy
TUnit (basic)	1.* wildcard — users always get the latest minor
TUnit.AspNet	Pinned exact (1.39.0)
TUnit.FSharp	Pinned exact (1.39.0)
TUnit.AspNet.FSharp	Pinned exact (1.39.0)
TUnit.VB	Pinned exact (1.39.0)
TUnit.Playwright	Pinned exact (1.39.0)

The canonical TUnit template uses a wildcard, which means its scaffold always gets the current-latest TUnit without needing a Renovate bump. The language/framework-specific templates use pinned versions, which require Renovate PRs like this one to stay current and create a window where freshly-scaffolded projects reference a slightly stale version.

This inconsistency is pre-existing and again out of scope for this PR, but aligning all template project files to 1.* (or [1,2) to be NuGet-semver-safe) would eliminate this class of maintenance PR entirely for the template projects.

Auto-Merge Assessment

With auto-merge enabled (squash), CI checks in progress, and no review comments to address, this PR is following the standard Renovate bot workflow for the repository. The changes are low-risk (no production logic, only version strings) and consistent with prior version-bump PRs.

This PR is good to merge once CI passes.