¿Por qué se recurre al patrón Deferred Promise al evaluar componentes asíncronos?

Deferred Promise separa la instanciación de la promesa de su momento de resolución. Esto permite que el test examine de forma determinista el estado intermedio de carga (fallbacks de Suspense o skeletons) en el DOM, tras lo cual invoca deferred.resolve(payload) para confirmar la entrega de los datos, erradicando tests intermitentes (Flaky Tests).

¿Cómo se prueba el comportamiento de una UI optimista gestionada con useOptimistic en React 19?

El test dispara el envío del formulario y comprueba de inmediato la inclusión del elemento provisional en el DOM con atributos de estado pendiente (aria-busy='true' o badge de guardado) mientras la promesa del mock del backend sigue pendiente. Una vez resulta la promesa, el test valida que el estado optimista se consolide con los datos definitivos del servidor.

¿Cuál es la forma adecuada de silenciar console.error en Vitest al probar Error Boundaries deliberadamente?

Dado que React emite trazas de error en console.error de forma incondicional aun cuando son capturadas por ErrorBoundary, se define un espía en beforeEach: const spy = vi.spyOn(console, 'error').mockImplementation(() => {}), y se restaura con spy.mockRestore() en afterEach. Esto previene avisos alarmistas de 'Uncaught Error' en los informes de CI/CD.

¿Qué ventajas aporta el hook useActionState de React 19 sobre useFormState?

useActionState es el estándar oficial de React 19 que releva a la versión experimental useFormState. Devuelve la tupla [state, formAction, isPending], suprimiendo la necesidad de recurrir a hooks complementarios como useFormStatus con el mero propósito de vigilar el estado de envío (pending) en el componente del formulario.

¿Cómo opera internamente el hook use(Promise) de React 19 al suspender un componente?

Si la promesa suministrada aún no se ha resuelto (estado pending), use() arroja la propia promesa (throw promise), interrumpiendo la fase de renderizado Fiber del componente. React captura la promesa en el ancestro más inmediato, despliega el fallback configurado y añade un listener .then() a la promesa. Al resolverse (settled), el planificador programa el re-renderizado del componente con el valor resuelto.

¿Cuál es la distinción fundamental entre una mutación estándar y una ejecutada con useTransition?

Las actualizaciones de estado estándar poseen prioridad síncrona y bloquean el procesamiento de entrada hasta concluir la reconciliación. Por contra, las actualizaciones dentro de startTransition se consideran transiciones concurrentes: React las computa en segundo plano con baja prioridad, preservando la interacción del usuario. Mientras se completan, la bandera isPending permanece en true.

¿Por qué crear promesas directamente en el cuerpo del componente genera un bucle infinito en Suspense?

Al suspenderse, el componente se desmonta para dar paso al fallback; cuando la promesa se resuelve, React reanuda el componente desde su primera línea. Si la promesa se instancia en dicho cuerpo, se genera una nueva promesa pendiente que vuelve a arrojarse a Suspense. Las promesas deben originarse externamente vía props, Server Components o mediante caché estable con cache().

¿Cómo previene waitForElementToBeRemoved condiciones de carrera al verificar spinners de carga?

waitForElementToBeRemoved supervisa el desmontaje efectivo del nodo en el DOM valiéndose de MutationObserver. Esto certifica que la fase de visualización del fallback de Suspense ha concluido y el DOM se ha actualizado antes de que el test proceda a buscar los elementos semánticos definitivos.

Pruebas de UI Asíncrona en React 19 — Pruebas y Automatización QA

Fundamentos Arquitectónicos#

La arquitectura de React 19 ha elevado la asincronía y la interacción con el planificador concurrente (Concurrent Scheduler) a un nuevo estándar de ingeniería. El patrón tradicional consistente en «obtener datos dentro de useEffect y gestionar banderas locales isLoading/error mediante useState» ha sido sustituido por primitivas declarativas en React 19:

El Hook use(Promise): Permite leer el resultado de una promesa directamente en el cuerpo funcional del componente durante la fase de renderizado, integrándose de forma nativa con el árbol <Suspense>.
Transiciones Concurrentes (useTransition): Permiten marcar las mutaciones de estado como transiciones en segundo plano no bloqueantes, preservando la capacidad de respuesta de la interfaz y exponiendo la bandera isPending.
Primitivas para Formularios (useActionState y useOptimistic): Estandarizan la gestión del ciclo de vida de acciones asíncronas de servidor y cliente, facilitando retroalimentación inmediata mediante mutaciones optimistas.
Límites de Errores (ErrorBoundary): Interceptan excepciones no controladas y promesas rechazadas (rejected promises), evitando caídas catastróficas de la aplicación hacia pantallas en blanco.

Probar componentes asíncronos en React 19 requiere comprender la mecánica de fases del planificador: un componente puede suspender su ejecución (suspend), arrojando la promesa hacia el límite <Suspense> ascendente más cercano, re-renderizarse tras la resolución de la microtarea o procesar transiciones en paralelo sin congelar el hilo principal.

use(Promise) y sus mecanismos complementarios transforman la metodología de pruebas: en lugar de aguardar la activación de un useEffect, el test asume el control directo del ciclo de vida de la promesa.

Modelo Mental#

Al procesar un componente que ejecuta use(promise), React examina el estado interno de la promesa. Si la promesa permanece en estado pending, React interrumpe la ejecución del nodo Fiber y monta la interfaz de respaldo (fallback, como skeletons o spinners) declarada por el componente <Suspense> padre más próximo.

En cuanto la promesa pasa al estado fulfilled, el planificador de React 19 programa un nuevo renderizado del componente con el valor resuelto. Si la promesa resulta rechazada (rejected), React propaga el error hacia el <ErrorBoundary> más cercano.

text

+-----------------------------------------------------------------------+
|              Component Render: const data = use(deferredPromise)      |
+-----------------------------------------------------------------------+
                                   │
         ┌─────────────────────────┴─────────────────────────┐
         ▼ (Promise: pending)                                ▼ (Promise: fulfilled)
+----------------------------------+       +------------------------------------+
| Fiber suspende el render.        |       | Se monta el contenido principal    |
| Se muestra el fallback:          |       | con los datos procesados:          |
| <Suspense fallback={<Skeleton/>}>|       | screen.getByText(data.title)       |
+----------------------------------+       +------------------------------------+
                 │                                           ▲
                 ▼ (En test: deferred.resolve(payload))       │
+------------------------------------------------------------+
| Resolución de promesa -> React programa re-renderizado     |
+------------------------------------------------------------+

El Patrón Deferred Promise para Pruebas con Suspense#

Con el propósito de evaluar de forma determinista tanto la fase del skeleton de carga como la presentación definitiva de los datos, el test debe controlar con precisión el instante de resolución. Para ello se emplea una factoría createDeferredPromise<T>():

typescript

export interface DeferredPromise<T> {
  readonly promise: Promise<T>;
  readonly resolve: (value: T) => void;
  readonly reject: (reason: unknown) => void;
}

export function createDeferredPromise<T>(): DeferredPromise<T> {
  let resolve!: (value: T) => void;
  let reject!: (reason: unknown) => void;

  const promise = new Promise<T>((res, rej) => {
    resolve = res;
    reject = rej;
  });

  return { promise, resolve, reject };
}

Sintaxis y API#

1. Pruebas de `use(Promise)` y `<Suspense>`#

Cualquier componente que invoque use() debe montarse necesariamente dentro de un límite <Suspense>:

typescript

import { Suspense, use } from 'react';

function UserCard({ userPromise }: { readonly userPromise: Promise<{ name: string }> }) {
  const user = use(userPromise);
  return <div>Usuario: {user.name}</div>;
}

// En el test:
render(
  <Suspense fallback={<div role="status">Cargando...</div>}>
    <UserCard userPromise={deferred.promise} />
  </Suspense>
);

2. Pruebas de `useTransition` e `isPending`#

El hook useTransition devuelve la tupla [isPending, startTransition]. En las pruebas resulta esencial validar el estado transitorio isPending antes de culminar las microtareas:

typescript

const [isPending, startTransition] = useTransition();

// Inicio de actualización no bloqueante
startTransition(async () => {
  await updateData();
});

3. Pruebas de `useActionState` (Acciones de React 19)#

El hook useActionState sustituye al anterior useFormState:

typescript

const [state, formAction, isPending] = useActionState(
  async (prevState: State, formData: FormData) => {
    return await saveArticleAction(formData);
  },
  initialState
);

Patrones Prácticos#

Patrón 1: Ciclo Completo de Suspense con `use(Promise)` y Deferred Promise#

El test corrobora la visualización del skeleton, posteriormente resuelve la promesa y valida la interfaz definitiva.

typescriptsrc/components/MetricWidget.test.tsx

import { describe, it, expect } from 'vitest';
import { render, screen, waitForElementToBeRemoved } from '@testing-library/react';
import React, { Suspense, use } from 'react';

interface MetricData {
  readonly activeUsers: number;
  readonly latencyMs: number;
}

function MetricContent({ dataPromise }: { readonly dataPromise: Promise<MetricData> }) {
  const data = use(dataPromise);

  return (
    <article aria-label="Métricas de rendimiento">
      <p>Sesiones activas: {data.activeUsers}</p>
      <p>Latencia media: {data.latencyMs} ms</p>
    </article>
  );
}

function MetricWidget({ dataPromise }: { readonly dataPromise: Promise<MetricData> }) {
  return (
    <Suspense fallback={<div role="status">Inicializando métricas...</div>}>
      <MetricContent dataPromise={dataPromise} />
    </Suspense>
  );
}

// Factoría de promesa gestionada
function createDeferredPromise<T>() {
  let resolve!: (value: T) => void;
  let reject!: (reason: unknown) => void;

  const promise = new Promise<T>((res, rej) => {
    resolve = res;
    reject = rej;
  });

  return { promise, resolve, reject };
}

describe('MetricWidget with React 19 use(Promise)', () => {
  it('muestra el skeleton de respaldo antes de resolver la promesa y los datos después', async () => {
    const deferred = createDeferredPromise<MetricData>();

    render(<MetricWidget dataPromise={deferred.promise} />);

    // 1. Verificar la presencia del fallback de Suspense
    const fallback = screen.getByRole('status');
    expect(fallback).toHaveTextContent('Inicializando métricas...');

    // La sección principal aún no debe figurar en el DOM
    expect(
      screen.queryByRole('region', { name: 'Métricas de rendimiento' })
    ).not.toBeInTheDocument();

    // 2. Resolver la promesa con los datos
    deferred.resolve({ activeUsers: 1420, latencyMs: 14 });

    // 3. Esperar la eliminación del indicador de carga
    await waitForElementToBeRemoved(() => screen.queryByRole('status'));

    // 4. Validar el renderizado final de las métricas
    expect(
      screen.getByRole('region', { name: 'Métricas de rendimiento' })
    ).toBeInTheDocument();
    expect(screen.getByText('Sesiones activas: 1420')).toBeInTheDocument();
    expect(screen.getByText('Latencia media: 14 ms')).toBeInTheDocument();
  });
});

Patrón 2: Pruebas de Transiciones Concurrentes con `useTransition` y Estado `isPending`#

Al conmutar pestañas o aplicar filtros sobre tablas, useTransition permite mostrar el progreso sin bloquear la capacidad interactiva del usuario.

typescriptsrc/components/TabNavigator.test.tsx

import { describe, it, expect, vi } from 'vitest';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import React, { useState, useTransition } from 'react';

interface TabProps {
  readonly onTabChange: (tab: string) => Promise<void>;
}

function TabNavigator({ onTabChange }: TabProps) {
  const [activeTab, setActiveTab] = useState('overview');
  const [isPending, startTransition] = useTransition();

  const handleSelect = (tab: string) => {
    startTransition(async () => {
      await onTabChange(tab);
      setActiveTab(tab);
    });
  };

  return (
    <nav aria-label="Secciones analíticas">
      <button
        type="button"
        aria-selected={activeTab === 'overview'}
        onClick={() => handleSelect('overview')}
      >
        Resumen
      </button>

      <button
        type="button"
        aria-selected={activeTab === 'realtime'}
        onClick={() => handleSelect('realtime')}
      >
        Tiempo Real
      </button>

      {isPending && <span role="progressbar">Cambiando sección...</span>}
      <div role="tabpanel">Sección actual: {activeTab}</div>
    </nav>
  );
}

describe('TabNavigator with useTransition', () => {
  it('refleja el estado isPending durante una transición asíncrona', async () => {
    const user = userEvent.setup();

    let resolveTransition!: () => void;
    const transitionPromise = new Promise<void>((res) => {
      resolveTransition = res;
    });

    const mockTabChange = vi.fn().mockImplementation(() => transitionPromise);

    render(<TabNavigator onTabChange={mockTabChange} />);

    const realtimeBtn = screen.getByRole('button', { name: 'Tiempo Real' });
    expect(screen.getByRole('tabpanel')).toHaveTextContent('Sección actual: overview');
    expect(screen.queryByRole('progressbar')).not.toBeInTheDocument();

    // Clic sobre la nueva pestaña
    await user.click(realtimeBtn);

    // Durante la espera de la promesa, el indicador de progreso debe montarse
    expect(screen.getByRole('progressbar')).toBeInTheDocument();

    // Resolver la transición
    resolveTransition();

    // La barra de progreso desaparece y la pestaña cambia
    await screen.findByText('Sección actual: realtime');
    expect(screen.queryByRole('progressbar')).not.toBeInTheDocument();
  });
});

Patrón 3: Pruebas de Formularios con `useActionState` e Interfaz Optimista (`useOptimistic`)#

React 19 consolida el tratamiento de acciones en formularios. Con useOptimistic, la interfaz se actualiza al instante sin aguardar la confirmación del servidor.

typescriptsrc/components/TaskTracker.test.tsx

import { describe, it, expect, vi } from 'vitest';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import React, { useActionState, useOptimistic } from 'react';

interface Task {
  readonly id: string;
  readonly title: string;
  readonly pending?: boolean;
}

interface TaskTrackerProps {
  readonly initialTasks: readonly Task[];
  readonly onAddTask: (title: string) => Promise<Task>;
}

function TaskTracker({ initialTasks, onAddTask }: TaskTrackerProps) {
  const [tasks, formAction, isPending] = useActionState(
    async (prevTasks: readonly Task[], formData: FormData) => {
      const title = formData.get('title') as string;
      if (!title) return prevTasks;

      // La tarea optimista ya es visible
      const savedTask = await onAddTask(title);
      return [...prevTasks, savedTask];
    },
    initialTasks
  );

  const [optimisticTasks, setOptimisticTasks] = useOptimistic(
    tasks,
    (current: readonly Task[], newTitle: string) => [
      ...current,
      { id: 'temp-id', title: newTitle, pending: true },
    ]
  );

  const handleSubmit = (formData: FormData) => {
    const title = formData.get('title') as string;
    setOptimisticTasks(title);
    return formAction(formData);
  };

  return (
    <section>
      <h2>Lista de tareas</h2>
      <form action={handleSubmit} aria-label="Añadir tarea">
        <input name="title" aria-label="Título de nueva tarea" />
        <button type="submit" disabled={isPending}>
          Añadir
        </button>
      </form>

      <ul aria-label="Tareas">
        {optimisticTasks.map((t) => (
          <li key={t.id} aria-busy={Boolean(t.pending)}>
            {t.title} {t.pending && '(Guardando...)'}
          </li>
        ))}
      </ul>
    </section>
  );
}

describe('TaskTracker with useActionState & useOptimistic', () => {
  it('renderiza el elemento optimista inmediatamente y consolida con la respuesta del servidor', async () => {
    const user = userEvent.setup();

    let resolveServerAction!: (task: Task) => void;
    const serverPromise = new Promise<Task>((res) => {
      resolveServerAction = res;
    });

    const mockAddTask = vi.fn().mockImplementation(() => serverPromise);

    render(
      <TaskTracker
        initialTasks={[{ id: '1', title: 'Aprender React 19' }]}
        onAddTask={mockAddTask}
      />
    );

    const input = screen.getByRole('textbox', { name: 'Título de nueva tarea' });
    const submitBtn = screen.getByRole('button', { name: 'Añadir' });

    await user.type(input, 'Escribir pruebas unitarias');
    await user.click(submitBtn);

    // 1. La entrada optimista figura síncronamente antes de la respuesta del servidor
    expect(
      screen.getByText(/Escribir pruebas unitarias \(Guardando\.\.\.\)/)
    ).toBeInTheDocument();

    // 2. Resolución de la acción en el servidor
    resolveServerAction({ id: 'srv-99', title: 'Escribir pruebas unitarias' });

    // 3. El indicador temporal desaparece y la tarea definitiva queda registrada
    const finalItem = await screen.findByText('Escribir pruebas unitarias');
    expect(finalItem).toBeInTheDocument();
    expect(screen.queryByText(/Guardando\.\.\./)).not.toBeInTheDocument();
  });
});

Patrón 4: Verificación de Captura de Excepciones mediante `ErrorBoundary`#

Cuando una promesa asíncrona evaluada con use(Promise) se rechaza o un componente arroja una excepción, ErrorBoundary debe presentar la interfaz de contingencia sin desestabilizar el test runner ni saturar la consola.

typescriptsrc/components/SafeAsyncBoundary.test.tsx

import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';
import { render, screen } from '@testing-library/react';
import React, { Component, Suspense, use, type ReactNode, type ErrorInfo } from 'react';

interface ErrorBoundaryProps {
  readonly children: ReactNode;
  readonly fallback: (error: Error) => ReactNode;
}

interface ErrorBoundaryState {
  readonly error: Error | null;
}

class SafeErrorBoundary extends Component<ErrorBoundaryProps, ErrorBoundaryState> {
  override state: ErrorBoundaryState = { error: null };

  static getDerivedStateFromError(error: Error): ErrorBoundaryState {
    return { error };
  }

  override componentDidCatch(error: Error, info: ErrorInfo) {
    // En producción: envío de telemetría hacia Sentry
  }

  override render() {
    if (this.state.error) {
      return this.props.fallback(this.state.error);
    }
    return this.props.children;
  }
}

function BrokenComponent({ dataPromise }: { readonly dataPromise: Promise<string> }) {
  const result = use(dataPromise);
  return <div>Datos: {result}</div>;
}

describe('SafeErrorBoundary with Rejected use(Promise)', () => {
  let consoleErrorSpy: ReturnType<typeof vi.spyOn>;

  beforeEach(() => {
    // Silenciamos la traza de excepción no controlada en el stderr del test runner
    consoleErrorSpy = vi.spyOn(console, 'error').mockImplementation(() => {});
  });

  afterEach(() => {
    consoleErrorSpy.mockRestore();
  });

  it('captura la promesa rechazada de use() y muestra el fallback de error', async () => {
    const rejectedPromise = Promise.reject(new Error('Gateway Timeout 504'));

    render(
      <SafeErrorBoundary
        fallback={(err) => (
          <div role="alert">
            <h2>Error de carga</h2>
            <p>{err.message}</p>
          </div>
        )}
      >
        <Suspense fallback={<div>Cargando...</div>}>
          <BrokenComponent dataPromise={rejectedPromise} />
        </Suspense>
      </SafeErrorBoundary>
    );

    // Esperar de manera asíncrona a que el Error Boundary procese el fallo
    const alert = await screen.findByRole('alert');
    expect(alert).toHaveTextContent('Error de carga');
    expect(alert).toHaveTextContent('Gateway Timeout 504');
  });
});

Errores Frecuentes#

Ошибка: Instanciar la Promise dentro del cuerpo funcional sin memoización antes de use()

Declarar promesas en pleno renderizado (const p = fetch(...)) provoca que en cada reintento de Suspense se genere una instancia inédita, incurriendo en un bucle infinito de Suspense (Infinite Suspense Loop).

typescript

// ❌ ANTIPATRÓN: La promesa se crea de nuevo en cada tick de render
function BadProfile() {
  const data = use(fetch('/api/user')); // ¡Bucle infinito!
  return <div>{data.name}</div>;
}

// ✅ SOLUCIÓN: La promesa se transmite por props o proviene de una caché estable
function GoodProfile({ userPromise }: { readonly userPromise: Promise<User> }) {
  const data = use(userPromise);
  return <div>{data.name}</div>;
}

Ошибка: Omitir la espera a la desaparición del fallback skeleton

Consultar de forma síncrona el contenido con screen.getByRole(...) prescindiendo de findBy* o waitForElementToBeRemoved derivará en fallos porque React aún se encuentra en estado de suspensión.

typescript

// ❌ ANTIPATRÓN: Consulta síncrona hacia contenido que aún no se ha montado
deferred.resolve({ id: 1 });
expect(screen.getByText('Contenido')).toBeInTheDocument(); // ¡Fallo!

// ✅ SOLUCIÓN: Espera asíncrona tras el desmontaje del skeleton
deferred.resolve({ id: 1 });
await waitForElementToBeRemoved(() => screen.queryByRole('status'));
expect(await screen.findByText('Contenido')).toBeInTheDocument();

Ошибка: Contaminar la salida de pruebas con console.error al testear ErrorBoundary

React registra por omisión las excepciones capturadas en console.error aun cuando sean atrapadas por componentDidCatch. Esto puede suscitar falsas alarmas en pipelines de CI.

typescript

// ❌ ANTIPATRÓN: Traza de excepción no controlada en la salida del test
render(<SafeErrorBoundary><FailingComponent /></SafeErrorBoundary>);

// ✅ SOLUCIÓN: Silenciar console.error con vi.spyOn durante la ejecución del test
beforeEach(() => {
  vi.spyOn(console, 'error').mockImplementation(() => {});
});
afterEach(() => {
  vi.restoreAllMocks();
});

Ошибка: Tratar de emular useTransition con un act() síncrono

Una transición ejecutada dentro de startTransition(async () => ...) planifica tareas concurrentes de baja prioridad. El act síncrono no espera la resolución de microtareas asíncronas anidadas.

typescript

// ❌ ANTIPATRÓN: act síncrono no aguarda microtareas de transición
act(() => {
  startTransition(() => { fetchData(); });
});

// ✅ SOLUCIÓN: Utilizar await act() o resolver con findBy
await act(async () => {
  await triggerAsyncTransition();
});

Fases de Pruebas de UI Asíncrona en React 19

Construcción de Promesa ControladaDeferred Setup

Inicializar un Deferred Promise con createDeferredPromise() exponiendo callbacks resolve/reject.

Montaje con Suspense y ErrorBoundaryMount

Envolver el componente en límites defensivos para interceptar estados pendientes o rechazados.

Validación del Skeleton de RespaldoAssert Fallback

Verificar la presencia del indicador de carga mediante getByRole('status' | 'progressbar').

Resolución de la Promesa (Resolve / Reject)Settle

Invocar manualmente deferred.resolve(data) o deferred.reject(error) para modificar el estado.

Sincronización y Aserción FinalFinal Assert

Aguardar el desmontaje del skeleton (waitForElementToBeRemoved) y verificar la UI definitiva.

Preguntas de Entrevista#

Preguntas de entrevista8 preguntas

Temas Relacionados#

Temas relacionados

Filosofía de React Testing Library (RTL)— Principios de Kent C. Dodds y consultas semánticas.Emulación de Acciones de Usuario con user-event v14+— Cascada de eventos del navegador y envío de formularios.Pruebas de Hooks Personalizados con renderHook()— Aislamiento de hooks, act() y waitFor.Simulación de Red con Mock Service Worker (MSW 2.x)— Intercepción de tráfico de red y simulación de retardos.

Pruebas de UI Asíncrona en React 19

Fundamentos Arquitectónicos#

Modelo Mental#

El Patrón Deferred Promise para Pruebas con Suspense#

Sintaxis y API#

1. Pruebas de use(Promise) y <Suspense>#

2. Pruebas de useTransition e isPending#

3. Pruebas de useActionState (Acciones de React 19)#

Patrones Prácticos#

Patrón 1: Ciclo Completo de Suspense con use(Promise) y Deferred Promise#

Patrón 2: Pruebas de Transiciones Concurrentes con useTransition y Estado isPending#

Patrón 3: Pruebas de Formularios con useActionState e Interfaz Optimista (useOptimistic)#

Patrón 4: Verificación de Captura de Excepciones mediante ErrorBoundary#

Errores Frecuentes#

Ошибка: Instanciar la Promise dentro del cuerpo funcional sin memoización antes de use()

Ошибка: Omitir la espera a la desaparición del fallback skeleton

Ошибка: Contaminar la salida de pruebas con console.error al testear ErrorBoundary

Ошибка: Tratar de emular useTransition con un act() síncrono

Preguntas de Entrevista#

Temas Relacionados#

Fundamentos Arquitectónicos#

Modelo Mental#

El Patrón Deferred Promise para Pruebas con Suspense#

Sintaxis y API#

1. Pruebas de use(Promise) y <Suspense>#

2. Pruebas de useTransition e isPending#

3. Pruebas de useActionState (Acciones de React 19)#

Patrones Prácticos#

Patrón 1: Ciclo Completo de Suspense con use(Promise) y Deferred Promise#

Patrón 2: Pruebas de Transiciones Concurrentes con useTransition y Estado isPending#

Patrón 3: Pruebas de Formularios con useActionState e Interfaz Optimista (useOptimistic)#

Patrón 4: Verificación de Captura de Excepciones mediante ErrorBoundary#

Errores Frecuentes#

Ошибка: Instanciar la Promise dentro del cuerpo funcional sin memoización antes de use()

Ошибка: Omitir la espera a la desaparición del fallback skeleton

Ошибка: Contaminar la salida de pruebas con console.error al testear ErrorBoundary

Ошибка: Tratar de emular useTransition con un act() síncrono

Preguntas de Entrevista#

Temas Relacionados#

1. Pruebas de `use(Promise)` y `<Suspense>`#

2. Pruebas de `useTransition` e `isPending`#

3. Pruebas de `useActionState` (Acciones de React 19)#

Patrón 1: Ciclo Completo de Suspense con `use(Promise)` y Deferred Promise#

Patrón 2: Pruebas de Transiciones Concurrentes con `useTransition` y Estado `isPending`#

Patrón 3: Pruebas de Formularios con `useActionState` e Interfaz Optimista (`useOptimistic`)#

Patrón 4: Verificación de Captura de Excepciones mediante `ErrorBoundary`#

1. Pruebas de `use(Promise)` y `<Suspense>`#

2. Pruebas de `useTransition` e `isPending`#

3. Pruebas de `useActionState` (Acciones de React 19)#

Patrón 1: Ciclo Completo de Suspense con `use(Promise)` y Deferred Promise#

Patrón 2: Pruebas de Transiciones Concurrentes con `useTransition` y Estado `isPending`#

Patrón 3: Pruebas de Formularios con `useActionState` e Interfaz Optimista (`useOptimistic`)#

Patrón 4: Verificación de Captura de Excepciones mediante `ErrorBoundary`#