Tus tests Playwright, verificados por Delta-QA. Una línea por página a verificar.
@delta-qa/vision envía a Delta-QA cada página que verifican tus pruebas de Playwright. Delta-QA la compara con su referencia elemento por elemento y te dice qué elemento ha cambiado. Tus pruebas de regresión escritas en código y tus escenarios grabados sin código viven en el mismo espacio de trabajo: mismas referencias, misma revisión, mismo informe.
El SDK Vision está disponible primero en acceso anticipado: contáctanos para usarlo con tus tests Playwright.
Tres pasos en tus tests
- Crea una clave de API en tu espacio de trabajo Delta-QA y guárdala en un secreto de tu CI. El SDK la lee en
DELTAQA_API_KEY; el espacio es el de la clave. - Añade un check donde tu test deba verificar la página:
vision.check("Pago"). Su nombre lo empareja con su referencia. - Haz push. En la primera ejecución, cada test es «Nuevo»: su primera captura se convierte en la referencia. En la segunda, con el sitio sin cambios, no se señala ninguna diferencia.
import { test } from "@playwright/test";
import { Vision } from "@delta-qa/vision";
const vision = new Vision(); // reads DELTAQA_API_KEY
test("Checkout", async ({ page }) => {
await vision.open(page, { id: "checkout", name: "Checkout" });
await page.goto("https://shop.example.com/checkout");
await vision.check("Payment");
await vision.close(); // fails the test on an unreviewed difference
});El SDK solo expone ajustes que Delta-QA aplica: ninguno se acepta sin efecto. El tag y el tag de referencia son opcionales; sin ellos, el SDK los deduce.
Una comparación elemento por elemento, no por píxeles
En cada verificación, el SDK envía la página (su HTML, el viewport) y los recursos que cargó el navegador. Delta-QA vuelve a abrir la página y compara sus elementos con los de la referencia, como un paso de escenario: el informe dice qué elemento ha cambiado — el botón «Pagar», de azul a verde —, no una zona de píxeles.
Una diferencia sin revisar hace fallar la prueba de Playwright, y el registro de la CI da el enlace del lote. Abres el paso, lees el informe y decides: «Esperado» o «Bug».
Cada recurso se reconoce por su hash: un recurso que tu espacio de trabajo ya tiene no se vuelve a enviar nunca. En la segunda ejecución de una suite, con el sitio sin cambios, solo salen el HTML y los hashes.
Una referencia por rama, sin fusión automática
- El tag se deduce de tu rama de git o de la CI, y el tag de referencia del destino de la PR, o si no de
main. Una rama nueva se compara conmaindesde su primera ejecución, y el lote muestra «comparado con main». - «Esperado» se aplica a los tags que marques, «solo este tag» por defecto: las demás ramas no ven ningún cambio.
- El historial de una prueba se filtra por entorno y por tag; cualquier análisis puede fijarse como referencia, para los tags que marques.
- Las pruebas de una ejecución de CI forman un lote, compartido por las máquinas que corren en paralelo; la lista de lotes se lee como tu CI.
Preguntas sobre el SDK Vision
¿Qué frameworks cubre el SDK Vision?
¿Tengo que reescribir mis tests Playwright?
¿Qué datos envía el SDK?
¿Cambian mis escenarios sin código?
¿Puedo usarlo desde otro lenguaje?
Haz que Delta-QA verifique tus tests Playwright
Para usar Vision, contáctanos: está disponible primero en acceso anticipado. Cuéntanos qué tests quieres verificar y te abrimos el acceso.