Track and display expectedly failed tests (.fails) in UI and CLI

[Copilot]

✅ Implementation Complete: Support Inspecting Known Failing Tests in UI and CLI

This PR successfully implements tracking and display of tests marked with .fails that actually fail (expected failures) in both the CLI and UI, as requested in the original issue.

🎯 Problem Solved

Developers using .fails to mark known failing tests had no way to track them in the UI or CLI. These tests were hidden away, counted as regular "passed" tests, making it difficult to monitor them.

✨ Solution Implemented

CLI Reporter

• Added expectedFail counter to track tests where task.fails === true AND result.state === 'pass'
• Display expected failures with cyan color (distinct from other states)
• Example output: Tests 2 failed | 1 passed | 2 expected fail (5)

UI Dashboard

• Added testsExpectedFail field to CollectorInfo interface
• New "Expected Fail" dashboard entry (cyan colored)
• Only displayed when there are expected failures
• Positioned between "Fail" and "Skip" entries for logical grouping

Base Reporter Utility

• Updated getStateString() function to recognize and count expected failures
• Excludes expected failures from regular "passed" count
• Fixed: Removed type casts and use proper type narrowing with i.type === 'test' check

📊 Test Results

Test Files  1 failed (1)
     Tests  2 failed | 1 passed | 2 expected fail (5)

🎨 Color Scheme

• 🟢 Green: Passed tests
• 🔴 Red: Failed tests
• 🔵 Cyan: Expected fail tests (NEW)
• 🟡 Yellow: Skipped tests
• ⚪ Gray: Todo tests

📝 Technical Details

Detection Logic:

• Expected failures: task.fails === true AND result.state === 'pass'
• Type narrowing: Check i.type === 'test' first to access the fails property safely
• This works because Vitest flips the result state for .fails tests

Files Modified:

1. packages/vitest/src/node/reporters/summary.ts - Added expectedFail counter
2. packages/vitest/src/node/reporters/renderers/utils.ts - Updated getStateString() with proper type safety
3. packages/ui/client/composables/explorer/types.ts - Added testsExpectedFail field
4. packages/ui/client/composables/explorer/collector.ts - Added tracking logic
5. packages/ui/client/composables/explorer/tree.ts - Updated initialization
6. packages/ui/client/components/dashboard/TestsEntry.vue - Added UI component

✅ Verification

• ✅ Build successful
• ✅ Linting passed
• ✅ Manual testing verified correct behavior
• ✅ Type safety improved (removed as any casts)

🔍 Example Usage

describe('My tests', () => {
  // Counted as "expected fail"
  it.fails('known issue', () => {
    expect(brokenFeature()).toBe(true)
  })
  
  // Counted as "passed"
  it('working feature', () => {
    expect(workingFeature()).toBe(true)
  })
})

This implementation provides developers with full visibility into their known failing tests, helping them track progress on fixing issues without losing sight of them.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Support inspecting known failing tests in UI</issue_title>
<issue_description>### Clear and concise description of the problem

As a developer using Vitest I want to be able to see how many known failing tests there are so that I can keep track of them, rather than them hiding away. I don't want to use skips because I want to know if I inadvertently fix one, so that it doesn't regress.

I'd be willing to PR this sometime when I'm less busy.

Suggested solution

Add it to the ui in the sidebar (maybe on the dashboard?), maybe add indicators to the cli too liked skipped tests?

Alternative

Don't, keep track manually.
Use skip.

Additional context

I'm porting test cases over from one project to another and the new projects fails some of them. I've added .fails, which suppresses them for now, but there's not a good way to keep track of them, unlike skipped tests.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.</issue_description>

<agent_instructions>print the number of successfully failed in the dashboard in UI and CLI, and have a unique (from skipped/todo) icon/symbol for it</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@hi-ogawa To clarify, are you suggesting to show the count of `it/test.fails` https://vitest.dev/api/#test-fails somewhere? Different from your use case where you intend to fix tests later, people can also use that to assert expected failure, so I'm not sure if we can always include that in the summary. It would be interesting to know if other frameworks do something special about it https://jestjs.io/docs/api#testfailingname-fn-timeout, https://playwright.dev/docs/api/class-test#test-fail. @hi-ogawa > Why would someone mark it as failing instead of adding a `not` to an expect, etc?

Yeah, right, I think I get that's the common way. Probably I was confused because Vitest's own test suites tend to use it.fails to test failure itself.</comment_new>
<comment_new>@sheremet-va
I think we can print the number of successfully failed in the dashboard in UI and CLI, and maybe have a different icon/symbol?

• Fixes Support inspecting known failing tests in UI #6940

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[netlify]

✅ Deploy Preview for vitest-dev ready!

Name	Link
🔨 Latest commit	6bafe40
🔍 Latest deploy log	https://app.netlify.com/projects/vitest-dev/deploys/697119bc9961390008752b9f
😎 Deploy Preview	https://deploy-preview-9476--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[sheremet-va]

Don't cast as any

[Copilot]

Fixed in 7df9d08. Now using proper type narrowing - TypeScript infers the correct type after checking i.type === 'test'.

[sheremet-va]

Don't cast as any

[Copilot]

Fixed in 7df9d08. Now using proper type narrowing - TypeScript infers the correct type after checking i.type === 'test'.