ViteBay

Vite Testing with Vitest: The Complete Guide to Modern Testing Setups & Alternatives

Vite Testing with Vitest: The Complete Guide to Modern Testing Setups & Alternatives

Introduction: Why Testing Matters in Modern Web Development

In the rapidly evolving landscape of web development, testing has transitioned from being an optional afterthought to an essential component of sustainable software engineering. This is where Vite Testing with Vitest becomes essential for modern development workflows. As applications grow in complexity and user expectations heighten, maintaining code quality through comprehensive testing becomes paramount. For developers working with Vite—the modern frontend build tool that has revolutionized development experiences—selecting the right testing strategy through Vite Testing with Vitest is crucial for leveraging Vite’s capabilities while ensuring application reliability.

The JavaScript ecosystem offers numerous testing solutions, with Jest long dominating the space. However, the recent surge in Vitest—a testing framework built specifically for Vite—represents a significant shift in how developers approach testing in modern web applications. This comprehensive guide explores Vitest and other non-Jest testing alternatives, providing detailed setup instructions, troubleshooting advice, and strategic guidance to help you implement effective testing practices in your Vite projects.

Why Vitest Matters: The Vite-Native Testing Solution

The Genesis of Vitest

Vitest emerged as a response to the growing need for a testing framework that could seamlessly integrate with Vite‘s tooling ecosystem. As Vite gained popularity for its lightning-fast development server and optimized build process, developers recognized the inefficiency of maintaining separate transformation pipelines for development and testing. Vitest, conceived by the same team behind Vite, addresses this fundamental disconnect by sharing Vite’s configuration, plugins, and transformation pipeline during testing.

This unified approach eliminates the configuration complexity that often plagues JavaScript testing setups. As one developer testimonial highlights: “If I have to summarize in one sentence why Vitest is so good compared to Jest, it is that you don’t need a PhD to configure all these things. You use the existing Vite configuration file and add a couple of lines to it, and that’s it. Your tests are working.”  This sentiment captures the core value proposition of Vitest: reducing configuration overhead while maintaining excellent performance and developer experience.

Key Advantages of Vitest

  • Unified Configuration: Vitest leverages your existing Vite configuration, eliminating the need for duplicate tooling setups for testing and development .
  • Jest Compatibility: Designed with familiarity in mind, Vitest implements most of Jest’s API, making migration straightforward for teams already familiar with Jest .
  • Exceptional Performance: By utilizing Vite’s transformation pipeline and implementing smart watch mode with Hot Module Replacement (HMR), Vitest provides significantly faster test execution, particularly in watch mode .
  • First-Class TypeScript Support: Unlike many testing frameworks that require complex transpilation configurations, Vitest handles TypeScript effortlessly through Vite’s native support .
  • Modern Feature Set: Vitest includes out-of-the-box support for ES modules, JSX, TSX, and modern web standards without additional configuration .

Understanding the Testing Landscape: Vitest vs. Alternatives

How Vitest Compares to Jest

While Jest has been the testing framework of choice for many JavaScript projects for years, Vitest presents a compelling alternative, especially for Vite-based projects:

FeatureJestVitest
ConfigurationSeparate configuration requiredShares Vite configuration
TransformationCustom transformation pipelineUses Vite’s transformation pipeline
Watch ModeTraditional file watchingHMR-powered watch mode
Plugin SystemJest-specific pluginsVite plugin ecosystem
Browser Supportjsdom environmentjsdom + potential browser mode
ES ModulesRequires configurationNative support

The fundamental distinction lies in Vitest’s architectural alignment with Vite. As the official Vitest documentation explains: “If your app is powered by Vite, having two different pipelines to configure and maintain is not justifiable. With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same vite.config.js.” 

Complementary Testing Tools

Vitest excels at unit testing and component testing, but a comprehensive testing strategy often incorporates multiple tools:

  • Cypress: Ideal for end-to-end testing and component testing in real browsers. The Vitest team explicitly recommends using “Vitest for all headless logic in your application and Cypress for all browser-based logic” .
  • Playwright: Another robust solution for cross-browser end-to-end testing, particularly valuable for verifying critical user workflows across different browser engines .
  • Web Test Runner: A browser-based testing tool that provides authentic browser environments without mocking, though it requires additional configuration to work with Vite projects .

These tools complement rather than compete with Vitest, addressing different testing needs within the same application.

Setting Up Vitest in Your Project

Installation and Basic Configuration

Setting up Vitest in a new or existing project is straightforward. Begin by installing Vitest as a development dependency:

# Using npm
npm install -D vitest

# Using yarn
yarn add -D vitest

# Using pnpm
pnpm add -D vitest

After installation, add a test script to your package.json:

{
  "scripts": {
    "test": "vitest",
    "test:run": "vitest run",
    "coverage": "vitest run --coverage"
  }
}

Vitest requires Vite ≥v6.0.0 and Node ≥v20.0.0 for optimal performance and feature compatibility . Ensure your environment meets these requirements before proceeding.

Configuring Vitest with Vite

One of Vitest’s key advantages is its ability to share Vite’s configuration. For most projects, you can simply add a test section to your existing vite.config.ts file:

/// <reference types="vitest" />
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: './src/test/setup.ts',
  },
})

The triple-slash reference directive ensures TypeScript recognizes Vitest’s configuration types . For projects not using Vite, you can create a separate vitest.config.ts file:

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    // ... your test configuration
  },
})

Testing React Components with Testing Library

To test React components with Vitest, you’ll need to configure DOM testing environment and utilities:

  1. Install necessary dependencies:
npm install -D @testing-library/react @testing-library/jest-dom @testing-library/user-event jsdom
  1. Create a setup file (src/test/setup.ts):
import '@testing-library/jest-dom'
  1. Update your Vite configuration to include this setup file and configure the testing environment:
export default defineConfig({
  // ... existing configuration
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: './src/test/setup.ts',
  },
})
  1. Write your component tests:
import App from './App'
import { render, screen } from '@testing-library/react'
import userEvent from '@testing-library/user-event'

describe('App component', () => {
  it('renders the title correctly', () => {
    render(<App />)
    expect(screen.getByText(/Vite \+ React/i)).toBeInTheDocument()
  })

  it('handles user interactions', async () => {
    render(<App />)
    await userEvent.click(screen.getByRole('button'))
    expect(await screen.findByText(/count is 1/i)).toBeInTheDocument()
  })
})

Writing Effective Tests with Vitest

Test Structure and Organization

Vitest provides a familiar testing API that will be comfortable for developers experienced with Jest or Mocha. The framework supports both describe/it and test syntax:

import { describe, it, expect } from 'vitest'
import { add } from './math'

describe('add function', () => {
  it('should return the sum of two numbers', () => {
    expect(add(1, 2)).toBe(3)
  })

  it('should handle negative numbers correctly', () => {
    expect(add(-1, -2)).toBe(-3)
  })
})

By default, Vitest recognizes test files with .test. or .spec. in their names, following common JavaScript testing conventions .

Advanced Testing Features

Vitest includes a comprehensive set of testing features that rival established frameworks:

  • Snapshot Testing: Capture and compare component outputs to prevent unexpected changes.
  • Mocking: Comprehensive mocking capabilities for functions, modules, and dependencies.
  • Code Coverage: Integrated coverage reporting with support for multiple providers (v8, istanbul).
  • Test Filtering: Run specific tests using .only, .skip, or CLI filters.
  • In-Source Testing: Write tests directly in source files for rapid prototyping and development.

To run specific tests, you can use Vitest’s filtering capabilities:

# Run tests matching a specific name pattern
npm test -- -t "add function"

# Run tests in a specific file
npm test src/math.test.ts

For focused development, you can temporarily modify your test cases:

// Run only this test
it.only('should focus on this test', () => {
  // test implementation
})

// Skip this test temporarily
it.skip('should skip this test', () => {
  // test implementation
})

Advanced Vitest Configuration and Optimization

Multi-Project Configuration

For complex codebases with different testing requirements across modules, Vitest supports project-based configurations:

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    projects: [
      {
        name: 'unit-tests',
        root: './src',
        environment: 'jsdom',
      },
      {
        name: 'integration-tests',
        root: './tests/integration',
        environment: 'node',
      },
    ],
  },
})

This approach allows you to run different test suites with distinct configurations in a single execution, streamlining your CI/CD pipeline .

Performance Optimization

Vitest’s performance is one of its standout features, but you can further optimize test execution through several strategies:

  • Dependency Pre-bundling: Leverage Vite’s dependency pre-bundling to reduce transformation overhead.
  • Worker Isolation: Configure worker threads to balance isolation and performance based on your test characteristics.
  • Selective Transformation: Use include/exclude patterns to avoid unnecessary file processing.

Recent Developments and Future Directions

Vitest v4 and Visual Regression Testing

The Vitest ecosystem continues to evolve rapidly, further cementing the importance of Vite Testing with Vitest in modern development workflows. The recent v4 beta introduces visual regression testing, expanding Vitest’s capabilities beyond traditional unit testing and marking a significant advancement for comprehensive Vite Testing with Vitest strategies. This feature leverages Vitest’s browser mode to capture and compare visual representations of components, addressing a critical testing need that previously required specialized tools.

Additionally, Vitest v4 reduces test startup time by approximately 25% on average, further enhancing the developer experience . These improvements demonstrate the project’s commitment to both expanding capabilities and refining core performance.

Security Considerations

Recent security vulnerabilities in development tools highlight the importance of maintaining updated dependencies. In April 2025, Vite addressed CVE-2025-31486, an arbitrary file read vulnerability affecting Vite development servers exposed to the network . The vulnerability affected multiple Vite versions and could allow unauthorized file access.

To mitigate such risks:

  • Keep dependencies updated regularly
  • Restrict development server exposure to untrusted networks
  • Monitor security advisories for your tooling ecosystem

The vulnerability was addressed in Vite versions 6.2.5, 6.1.4, 6.0.14, 5.4.17, and 4.5.12 . This incident underscores the importance of proactive dependency management in modern development workflows.

Migration Strategies: From Jest to Vitest

Incremental Migration Approach

For existing projects using Jest, migrating to Vitest doesn’t need to be an all-or-nothing endeavor. Vitest’s compatibility with Jest’s API facilitates a gradual migration:

  1. Start by installing Vitest alongside your existing Jest setup.
  2. Configure Vitest to handle a subset of your test files using the include option.
  3. Begin migrating tests one file or module at a time, leveraging Vitest’s watch mode for immediate feedback.
  4. Address compatibility gaps using Vitest’s compatibility layer or by implementing lightweight adapters.
  5. Once all tests are migrated, remove Jest dependencies and configuration.

This incremental approach minimizes disruption and allows teams to validate Vitest’s behavior against known test outcomes.

Configuration Comparison

Understanding the configuration differences between Jest and Vitest simplifies migration:

Jest ConfigurationEquivalent Vitest Configuration
testEnvironment: 'jsdom'environment: 'jsdom'
setupFilesAfterEnvsetupFiles
moduleNameMappingVite’s resolve.alias
transformHandled by Vite’s built-in transformation
coverageProvidercoverage: { provider: 'v8' }

What is the Best Testing Framework for Vite?

Given the deep integration and shared ecosystem, Vitest is unequivocally the best testing framework for Vite projects. While the “best” tool can sometimes be subjective, the architectural synergy between Vite and Vitest makes this a clear-cut case for several compelling reasons:

  1. The Architectural Advantage: Other testing frameworks like Jest operate with their own independent transformation pipelines. This means you configure how your code is transformed for tests separately from how it’s transformed for development and production. With Vite and Vitest, there is only one pipeline. This eliminates a massive source of configuration complexity and ensures your tests run in an environment that behaves identically to your development server.
  2. The Configuration Dream: The dream of a “zero-config” setup is largely realized with Vitest. If your Vite project is already set up to handle TypeScript, JSX, and path aliases, your Vitest setup automatically inherits all of it. There’s no need to duplicate jsdom settings, path mappings, or plugin configurations. As one developer aptly put it, “You use the existing Vite configuration file and add a couple of lines to it, and that’s it. Your tests are working.”
  3. Unmatched Developer Experience: Vitest’s watch mode, powered by Vite‘s Hot Module Replacement (HMR), is significantly faster than traditional file watchers. Tests often re-run in milliseconds, creating a fluid, uninterrupted workflow. This tight feedback loop is crucial for Test-Driven Development (TDD) and maintaining developer momentum.
  4. Future-Proof and Co-Evolving: As Vite introduces new features or optimizations, Vitest is immediately positioned to leverage them. They are built and maintained by the same core team, ensuring long-term compatibility and innovation. You won’t face the lag time or compatibility gaps that can occur when using a separate, independent testing framework.

When Might an Alternative Be “Best”?

While Vitest is the default champion for Vite, a pragmatic testing strategy is layered. Vitest excels at unit testing and component testing (in a simulated jsdom environment). However, the “best” overall strategy often involves using the right tool for each job:

  • For End-to-End (E2E) Testing: Frameworks like Cypress or Playwright are the best choice. They run your application in a real browser, simulating actual user interactions. The Vitest team itself recommends this layered approach: “Use Vitest for the headless logic in your application and Cypress for all browser-based logic.”
  • For Legacy Projects: If you are migrating a large, existing project from a Webpack/Jest setup and a full migration is too costly, sticking with Jest temporarily might be the most pragmatic choice, even within a Vite build.

Final Verdict: For the vast majority of Vite projects—especially new ones—Vitest is the best and most logical choice for unit and component testing. Its seamless integration, performance, and excellent developer experience are unmatched in the Vite ecosystem.

Best Practices for Testing with Vitest

Moving beyond basic setup, adhering to established best practices is what separates good test suites from great ones. A great test suite is reliable, maintainable, and provides genuine confidence. Here are the key best practices for testing with Vitest:

1. Structure and Organization

  • Clear Naming Conventions: Use descriptive names for your test files (e.g., ComponentName.test.ts), describe blocks (the unit under test), and it/test blocks (the expected behavior).
    • Good: it('should display an error message when the email is invalid', ...)
    • Bad: it('should work', ...)
  • The AAA Pattern (Arrange-Act-Assert): Structure every test logically into three distinct sections. This improves readability and makes it easy to identify where a test is failing. 
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import LoginForm from './LoginForm';

describe('LoginForm', () => {
  it('should call onSubmit with email and password', async () => {
    // Arrange: Set up the test data, mocks, and render the component.
    const mockOnSubmit = vi.fn();
    const testEmail = 'test@example.com';
    const testPassword = 'password123';

    render(<LoginForm onSubmit={mockOnSubmit} />);

    // Act: Perform the user interaction or function call.
    await userEvent.type(screen.getByLabelText(/email/i), testEmail);
    await userEvent.type(screen.getByLabelText(/password/i), testPassword);
    await userEvent.click(screen.getByRole('button', { name: /login/i }));

    // Assert: Check that the expected outcomes occurred.
    expect(mockOnSubmit).toHaveBeenCalledWith({
      email: testEmail,
      password: testPassword,
    });
  });
});
  • Isolate Tests: Each test should be independent and not rely on the state from a previous test. Use Vitest’s beforeEach, afterEach, beforeAll, and afterAll hooks to set up and tear down common state, but avoid creating hidden dependencies between tests.

2. Writing Effective and Reliable Tests

  • Test Behavior, Not Implementation: Focus on what the user sees and can do, not how the component implements it. This makes tests more resilient to refactoring.
    • Avoid: Testing internal state variables or specific function call orders within a component.
    • Prefer: Testing based on rendered output and user events.
  • Use vi.fn() for Mocks: Vitest’s mocking utilities are powerful and Jest-compatible. Always explicitly mock external dependencies and side-effects (like API calls) using vi.fn().
// Mocking an API module
import { fetchUser } from './api';

vi.mock('./api', () => ({
  fetchUser: vi.fn(),
}));

test('displays user data', async () => {
  // Arrange
  const mockUser = { name: 'John Doe' };
  fetchUser.mockResolvedValue(mockUser); // Mock the resolved value
  render(<UserProfile id="123" />);

  // Act & Assert
  expect(await screen.findByText('John Doe')).toBeInTheDocument();
});
  • Prefer findBy for Asynchronous Operations: When testing components that update asynchronously (e.g., after an API call), use Testing Library’s findBy queries which automatically wait for the element to appear.
  • Utilize vi.spyOn for Partial Mocks: Instead of mocking an entire module, sometimes you only need to spy on or mock a single function. vi.spyOn is perfect for this and can be easily restored.
import * as utils from './utils';

test('logs an error', () => {
  const consoleSpy = vi.spyOn(console, 'error').mockImplementation(() => {});
  const utilsSpy = vi.spyOn(utils, 'helperFunction').mockReturnValue('mocked value');

  // ... run your test

  expect(consoleSpy).toHaveBeenCalledWith('Expected error');
  // Restore mocks
  consoleSpy.mockRestore();
  utilsSpy.mockRestore();
});

3. Performance and Configuration

  • Leverage In-Source Testing for Libraries: If you are building a library, consider Vitest’s in-source testing. This allows you to write tests directly in the same file as the implementation, which can be stripped out during the build process. It’s excellent for testing private functions and keeping tests close to the code.
  • Configure Test Environments Appropriately: Use environment: 'jsdom' for component tests and environment: 'node' for utility functions and Node.js APIs. This prevents loading the heavy DOM environment for simple logic tests, speeding up your test suite.
  • Use include and exclude in Configuration: Be explicit about which files Vitest should search for tests. This prevents it from unnecessarily scanning node_modules or build directories. 
// vite.config.ts
export default defineConfig({
  test: {
    include: ['src/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],
    exclude: ['**/node_modules/**', '**/dist/**'],
  },
});

By following these best practices, you’ll build a Vitest test suite that is not just a checkbox for code coverage, but a robust, reliable safety net that empowers your team to refactor and ship new features with confidence.

Understanding the JavaScript Testing Landscape

The modern JavaScript testing landscape is not a monolithic ecosystem but rather a diverse and specialized toolkit. Understanding the different types of tests and the frameworks designed for them is crucial for building a reliable application. The landscape can be broadly categorized into three main layers, each with a different scope and purpose.

The Three Pillars of a Testing Strategy

  1. Unit Testing: This is the foundation, focusing on testing individual units of code—typically functions or classes—in complete isolation from each other and from external dependencies. The goal is to validate that each small part of your application works correctly on its own. Vitest and Jest are the dominant frameworks in this space, prized for their speed and developer experience .
  2. Integration Testing: This layer verifies that different units of code work together correctly. For example, testing that a service function properly calls a database module and returns the expected data. Many unit testing frameworks, including Vitest and Jest, are also perfectly capable of handling integration tests.
  3. End-to-End (E2E) Testing: This is the broadest test type, simulating real user scenarios from start to finish in a real browser environment. E2E tests validate that the entire application, with all its integrated parts (frontend, backend, database, network), works as expected from a user’s perspective. Cypress and Playwright are the leading frameworks here .

A Landscape of Specialized Tools

The following table summarizes the primary testing frameworks and their ideal use cases, illustrating how they form a complementary, rather than competitive, landscape :

FrameworkPrimary Testing TypeKey CharacteristicsBest For
VitestUnit & ComponentBlazing fast, Vite-native, Jest-compatible API .Testing isolated logic and components in Vite-based projects.
JestUnit & ComponentAll-in-one, battle-tested, zero-config for basic JS .Large projects needing a proven, reliable solution with a massive ecosystem.
MochaUnit & IntegrationHighly flexible, requires pairing with assertion libraries like Chai .Developers who want to assemble a custom testing stack with specific tools.
CypressEnd-to-End (E2E)Developer-friendly, real-time reloads, excellent debugger .Reliable testing of critical user workflows like login and checkout.
PlaywrightEnd-to-End (E2E)Cross-browser (Chromium, Firefox, WebKit), fast, and modern .Testing complex applications across multiple browsers and devices.

As the table shows, a robust testing strategy often involves using more than one tool. A common and highly effective pattern is to use Vitest for all headless logic (units and components) and a tool like Cypress or Playwright for all browser-based logic (E2E tests) . This combination ensures both development speed and application reliability.

Can Vitest Be Used for End-to-End Testing?

The short and direct answer is no, Vitest is not designed as a primary tool for traditional End-to-End testing.

Vitest is fundamentally architected as a unit and component testing framework. It runs in a Node.js environment and typically uses simulated browser environments like jsdom, which, while fast, are incomplete . They lack a real layout engine, a native JavaScript engine, and other critical browser APIs. This means you cannot use Vitest to test visual rendering, CSS effects, or complex user interactions that depend on a real browser’s behavior.

However, the landscape is evolving, and Vitest’s role is expanding with two key nuances:

1. Vitest’s “Browser Mode” (Experimental)

The Vitest team is developing an experimental “browser mode” . This feature runs your tests natively inside an actual browser, which theoretically allows for testing scenarios that are impossible in jsdom. While this is a significant step forward, it is important to understand its current place:

  • It’s not a replacement for Cypress/Playwright: Browser mode is still focused on a testing model suited for units and components, but in a real browser context. It does not aim to replicate the comprehensive workflow, auto-waiting, and debugging capabilities of dedicated E2E frameworks .
  • Architectural Difference: As noted in the Vitest guide, “Playwright component tests run in a Node.js process and control the browser remotely. Vitest’s browser mode runs tests natively in the browser” . This is a fundamental architectural distinction.

2. The Complementary Strategy: Vitest + E2E Framework

The most powerful and recommended approach is to use Vitest in tandem with a dedicated E2E framework. This strategy leverages the strengths of each tool :

  • Use Vitest for: Business logic, utility functions, React/Vue components (in isolation), hooks, and anything that doesn’t require a full browser. This is where its incredible speed in watch mode shines, giving you near-instant feedback during development.
  • Use Cypress or Playwright for: Testing complete user journeys like signing up, adding items to a cart, or checking out. These tools run your entire application in a real browser, catching environment-specific issues and verifying that all parts of your system work together .

Conclusion: For true, reliable end-to-end testing that gives you confidence in your application’s real-world behavior, you should adopt a dedicated E2E framework like Cypress or Playwright. Vitest remains the superior choice for the vast majority of your unit and component testing needs, and together they form a complete testing suite that ensures both the correctness of the parts and the whole.

Conclusion: Building a Future-Proof Testing Strategy for Modern Web Applications

The journey through the modern JavaScript testing landscape reveals a clear, strategic path for developers and teams building with Vite, with Vite Testing with Vitest emerging as the foundational approach. The era of a one-size-fits-all testing framework is over, replaced by a more sophisticated, layered approach that leverages specialized tools for their specific strengths.

Vite Testing with Vitest has firmly established itself as the cornerstone of testing for Vite projects. Its native integration, shared configuration, and exceptional performance in unit and component testing are unparalleled. For any team starting a new Vite project or looking to modernize an existing one’s testing setup, adopting Vite Testing with Vitest is the most impactful decision for improving developer experience and test execution speed. It solves the fundamental friction of maintaining dual transformation pipelines, making comprehensive testing not just feasible but enjoyable.

However, the true power of a robust testing strategy for Vite Testing with Vitest lies in understanding the boundaries and synergies between tools. Vitest is not, and is not intended to be, a silver bullet for all testing needs. Its architecture is optimized for the “headless” testing of logic and components in isolation. For the critical validation of real user journeys in authentic browser environments, dedicated E2E frameworks like Cypress and Playwright remain indispensable partners to the Vite Testing with Vitest approach, catching environment-specific bugs, network-related issues, and visual regressions that unit tests cannot.

Therefore, the optimal testing architecture for a modern web application is a complementary pyramid:

  1. A broad base of fast, reliable Vitest unit and component tests that validate individual pieces of logic and isolated component behavior, providing rapid feedback during development.
  2. A focused layer of integration tests, often also handled by Vitest, that ensure these units work together correctly.
  3. A narrow but critical peak of end-to-end tests using Cypress or Playwright that verify key user flows work seamlessly in a real browser, giving confidence in the fully integrated system.

This layered approach ensures both development velocity and production reliability. As the ecosystem evolves, with Vitest pushing the boundaries of unit testing performance and tools like Playwright enabling unprecedented cross-browser testing, the opportunity to build more resilient, high-quality web applications has never been greater. By strategically implementing Vitest at the foundation of your testing strategy and supplementing it with robust E2E tools, you equip your team not just to write tests, but to build with genuine confidence for the future.