Expose Pinia Colada devtools actions via headless API for E2E testing

[JessicaSachs]

Problem

In browser-driven E2E tests (Playwright, Cypress), I want a deterministic way to test UI states that are driven by async data fetching (loading, error, success). In Nuxt SSR applications, this is difficult to achieve reliably using network interception alone, since initial data is often hydrated from the SSR payload and may not trigger client-side requests.

Pinia Colada devtools already provide excellent controls for forcing these query states during development, but those controls are currently only accessible via the devtools UI. For E2E testing, interacting with the devtools UI directly is brittle and obscures test intent.

Feature request

Expose an opt-in, programmatic API that mirrors the existing Pinia Colada devtools actions and can be invoked headlessly from browser E2E tests.

Motivation

• Enables deterministic E2E testing of loading/error UI states
• Avoids reliance on network timing or interception, especially in SSR contexts
• Aligns E2E testing with existing developer workflows using Colada devtools
• Removes the need to automate clicks in the devtools UI

Conceptual API (illustrative)

// Mirrors the devtools UI actions
// API shape and exposure mechanism are open for discussion
coladaDevtools.actions.simulateLoading(['organizations'])
coladaDevtools.actions.simulateError(['organizations'])
coladaDevtools.actions.reset(['organizations'])
coladaDevtools.actions.invalidate(['organizations'])
coladaDevtools.actions.refetch(['organizations'])

Exposure

If <PiniaColadaDevtools> are enabled, globalThis should be decorated with the global namespace.

Open Questions

1. What do you think?
2. What's a good namespace?

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

🔗 Similar Issues

Related Issues

• Integrate all @pinia/colada-devtools functionality as an official Vue devtools plugin #357
• [BUG] Not compatible with pinia ^2.1 #87
• Feature Request: Allow external modules to provide colada options #408
• Feature Request: Make query composables awaitable for Suspense support #401
• Feature Request: Global Query Type Registry via Module Augmentation #431
• Testing Guide #253
• Query callbacks and mutation direct payload #411

👤 Suggested Assignees

• productdevbook
• segevfiner
• Hanmo123
• ChronicStone
• DellanX

---

🧪 Issue enrichment is currently in early access.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

[posva]

The more I think about this, the more I think we don’t require an extra abstraction: all of the actions can be achieved through the query cache and models are usually very good at understanding how to use it. I do think some helpers might be nice if they do more than just one function call to the query store, for example toggling a loading state

Do you have code samples that make tests hard to write? That would help me see what is currently missing

[JessicaSachs]

Yep. I just want to be able to test loading states. In particular, I want to be able to do it from a blackbox environment. It's possible to gain coverage for components dealing with async data handling in Nuxt using registerEndpoint but registerEndpoint is not available in blackbox environments (it requires you to have the Nuxt context available within the test) and it doesn't allow you granular control of loading states, only resolved responses.

// Playwright E2E test I want to write, ignore the fact that this is flaky.
// The real PW test implementation would create a deterministic "gate"
// usually spying on the network request
// However, in SSR you can't spy on the network request
// ...so... the thinking is I would just force Pinia Colada into a loading state

it('shows a skeleton while the query is loading', async ({ page }) => {
  await page.goto('/foo')
  await expect(page.getByTestId('foo-skeleton')).toBeVisible()
})

When I say "blackbox environment" I mean some Nuxt app I'm connecting to from a completely disparate Playwright or Cypress or Vitest + Playwright Core process.

In non-SSR environments it's possible to test this by using MSW or other network boundaries, but in an SSR app, it's not possible to force these states without reaching into internals.

Pinia Colada adding hooks to programmatically trigger loading states would be very clutch.

Here's a Vue component that matches the test:

<!-- pages/foo.vue -->
<template>
  <div>
    <div v-if="query.isLoading" data-testid="foo-skeleton" />
    <div v-else>{{ query.data?.message }}</div>
  </div>
</template>

<script setup lang="ts">
import { useQuery } from '@pinia/colada'

const query = useQuery({
  key: ['foo'],
  query: () => $fetch('/api/foo'),
})
</script>

It's very easy for this to be not Pinia Colada's concern, but it would make for a very sexy benefit to use Pinia Colada for Nuxt developers trying to make their testing lives much better.