Skip to content

[FEATURE]: Migrate FilesList table header tests to createTestingPinia() #7940

Description

@vitormattos

After the upgrade to Pinia 4 and @pinia/testing 2, some LibreSign component tests still create a real Pinia instance even when they only need predefined store state or need to verify that a store action was called.

Update the tests for the FilesList table header components to use createTestingPinia() where real store behavior is not required.

This should produce small and clear test suites that can be used as examples by future contributors.

Files in scope

Update these source/test pairs:

src/views/FilesList/FilesListTableHeaderButton.vue
src/tests/views/FilesList/FilesListTableHeaderButton.spec.ts
src/views/FilesList/FilesListTableHeader.vue
src/tests/views/FilesList/FilesListTableHeader.spec.ts

The test path and base name must continue to mirror the source file being tested.

What should be done

  • Replace the real Pinia setup with createTestingPinia() where the test does not depend on real store behavior.
  • Configure spy creation according to the existing Vitest setup.
  • Use initialState when a test requires predefined store state.
  • Keep actions stubbed when the test only needs to verify that an action was called.
  • Preserve real action behavior only when a test explicitly verifies a state change produced by that action.
  • Keep the setup for each component inside its corresponding test suite.
  • Do not create a shared helper for these two test suites.
  • Preserve the existing behavior and intent of every test.

For example:

  • a test that verifies whether clicking a button calls toggleSortBy can use a stubbed action;
  • a test that verifies an actual state transition may require real action behavior.

Avoid changing assertions merely to accommodate the new test setup.

Test organization

Tests associated with a source file must preserve the corresponding source path and base name.

When a test suite eventually requires multiple supporting files, they may be placed in a directory named after the tested source file:

src/views/FilesList/FilesListTableHeaderButton.vue

src/tests/views/FilesList/FilesListTableHeaderButton/
├── FilesListTableHeaderButton.spec.ts
├── fixtures.ts
└── mocks.ts

This issue does not require creating these directories or moving the existing test files.

Out of scope

  • Changing application behavior.
  • Migrating other Pinia-based tests.
  • Creating generic test helpers.
  • Moving or reorganizing unrelated test files.
  • Refactoring stores or production components.
  • Refactoring complex signing flows.
  • Replacing real Pinia in store unit tests.

Acceptance criteria

  • FilesListTableHeaderButton.spec.ts uses createTestingPinia() where real Pinia behavior is unnecessary.
  • FilesListTableHeader.spec.ts uses createTestingPinia() where real Pinia behavior is unnecessary.
  • Predefined store state is provided through initialState where appropriate.
  • Store actions are stubbed or executed intentionally according to what each test verifies.
  • The source/test path correspondence is preserved.
  • No shared test helper is introduced.
  • Existing test intent and application behavior remain unchanged.
  • Type checking and the affected tests pass.

Validation

npm run ts:check
npx vitest run \
  src/tests/views/FilesList/FilesListTableHeaderButton.spec.ts \
  src/tests/views/FilesList/FilesListTableHeader.spec.ts

Good first issue

This issue should be a good opportunity for new contributors to become familiar with the LibreSign frontend, file listing and upload flow.

Although the change is expected to be mostly frontend-focused, contributors should pay special attention to existing upload rules and automated test coverage.

Additional context

  • If you have questions, feel free to ask in this issue.
  • Give a ⭐️ star to this repository if you find LibreSign useful and would like to support the project.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Status
    0. Needs triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions