microsoft / microsoft/vscode-dotnettools

VSTest are failing in CI

Open
#3,246 0 comments 0 reactions 1 assignee View on GitHub

@peterwald is already working on this.

Since Jun 24, 2026.

area-test bug
Dominant language
No language data
Stars
321
Forks
54
Avg merge
2d 19h
Merged PRs (30d)
2

Description

Describe the issue

The test shave been disabled until the root cause is addressed.

Analysis by Copilot:

The hook ( nextControllerSuite.ts ) hung at this step:

[23:59:01] Opening VSTest solution...
[23:59:06] Waiting for VSTest test projects to be discovered... ✅
[23:59:12] Waiting for all 5 VSTest projects to appear in controller tree... ⛔ never completes
[00:01:01] ❌ Timeout (120s from hook start)

The Windows agent was slow to populate all 5 VSTest projects into the test‑controller tree. The problem is structural:

• sharedSetup sets the Mocha suite/hook budget to TEST_TIMEOUT(120s) × timeoutMultiplier . The multiplier is 2 on macOS, 1 elsewhere ( suiteUtilities.ts:14-29 ) — so macOS gets 240s, Windows/Linux only 120s.
• But the before all hook does many sequential waits, each with its own 60–120s withTimeout / waitForCondition guard (wait controller 60s, wait projects 120s, wait 5 projects 120s, build, expand, wait discovery 120s). Those inner guards are larger than the whole 120s hook budget, so they're meaningless — the hook dies first.
• Linux is fast enough to squeeze in under 120s; Windows is on the edge and tipped over. No product error appears in the log — it's pure slowness/flakiness.

This file was last changed 2026‑05‑12 (the "wait for all projects" block, by Peter Waldschmidt). PR 747156 only touches hot‑reload log formatting and hot‑reload test helpers — it does not touch the test‑explorer suite. The log() / waitForCondition used here are self‑contained and already used console.log before your PR.

Suggested fix

Short term: just re‑run the Windows leg — it's a flaky, unrelated timeout, and your PR is otherwise green.

Durable fix: give the test‑explorer discovery suite a realistic timeout instead of 120s, mirroring what the aspire / hotreload suites already do ( this.timeout(5 * 60_000 * timeoutMultiplier) ). Concretely, in registerNextTestExplorerSuite ( nextControllerSuite.ts:17-18 ):

suite(suiteTitle, function () {
sharedSetup(this)
this.timeout(5 * 60_000 * timeoutMultiplier) // hook does many sequential 60-120s waits; 120s total is too tight on Windows

Collect logs

https://devdiv.visualstudio.com/DevDiv/DevDiv%20Team/_build/results?buildId=14460885&view=logs&j=35719c88-37e2-5b6b-0cc4-0d94b6fd7e0d&t=032d9ea0-5ceb-5e90-5e69-0ae341c9c649&l=3038

Steps to reproduce

No response

Expected behavior

No response

Environment information

No response

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.