<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Playwright on Patrones — Exeal</title><link>https://patterns.exeal.com/tags/playwright/</link><description>Recent content in Playwright on Patrones — Exeal</description><generator>Hugo</generator><language>es-ES</language><lastBuildDate>Thu, 24 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://patterns.exeal.com/tags/playwright/index.xml" rel="self" type="application/rss+xml"/><item><title>Tests de aceptación de frontend sobre una imagen Docker ya construida</title><link>https://patterns.exeal.com/patterns/tests-aceptacion-frontend-sobre-imagen-construida/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>https://patterns.exeal.com/patterns/tests-aceptacion-frontend-sobre-imagen-construida/</guid><description>&lt;h2 id="problema"&gt;Problema&lt;/h2&gt;&#10;&lt;p&gt;Un frontend construido con Vite y servido como estático (nginx) no se despliega como código fuente: se despliega como imagen Docker. Una suite de Playwright que arranca contra &lt;code&gt;vite dev&lt;/code&gt; o contra un build en el propio runner de CI no ejercita nada de lo que hay entre ese código y el artefacto real — el &lt;code&gt;Dockerfile&lt;/code&gt;, si nginx sirve las rutas de la SPA correctamente, si el entrypoint que inyecta la configuración en tiempo de arranque (ver el patrón de runtime env config) realmente deja la app apuntando a la API correcta. Todo eso puede pasar los tests unitarios y de componente y romperse solo en la imagen empaquetada.&lt;/p&gt;</description></item></channel></rss>