DEV Community: Bezael Pérez

Spec-Driven Development: el método para construir con IA sin perder el control

Bezael Pérez — Thu, 09 Apr 2026 07:40:32 +0000

Tienes una idea. Le pides a Claude o Cursor que la construya. En 20 minutos tienes algo que funciona.

Dos semanas después, el proyecto es una bomba de tiempo. Cada feature nueva rompe algo. Nadie sabe por qué el código hace lo que hace. Y cada prompt al agente sale peor que el anterior porque el contexto se ha ido acumulando sin orden.

Eso no es un problema de la IA. Es un problema de proceso.

El vibe coding tiene un límite

El vibe coding es real. Funciona. Para prototipos, para explorar ideas, para hacer algo pequeño en un fin de semana.

Pero tiene un problema de escala.

Cuando el proyecto crece, el conocimiento sobre él vive en tu cabeza. En el historial de chats con el agente. En comentarios dispersos. Cuando quieres cambiar algo, tienes que reconstruir el contexto desde cero cada vez.

El agente ejecuta bien. El problema es que ejecuta lo que le dices. Y si lo que le dices es ambiguo, incompleto o contradictorio, el resultado también lo es.

Spec-Driven Development (SDD) resuelve exactamente eso.

Qué es SDD

Una frase lo resume:

La spec se convierte en el artefacto primario que dirige todo el trabajo posterior: implementación, tests, documentación, verificación.

En el desarrollo tradicional, el código es la fuente de verdad. La documentación sirve al código.

SDD invierte esa relación.

La spec no sirve al código. El código sirve a la spec.

Defines el comportamiento esperado antes de que empiece la implementación. Ese comportamiento está escrito en un documento que el agente puede leer, seguir y contra el que puede verificar su trabajo.

El agente ejecuta. Tú piensas. Cada uno en su sitio.

Lo que SDD no es

Antes de seguir, tres malentendidos comunes:

No es documentación que nadie lee. Una spec de SDD vive con el código, se versiona con el código, y cuando el proyecto cambia, la spec cambia. No es un PDF en Confluence que nadie ha abierto en dos años.

No es waterfall. SDD describe el destino, no el camino. El destino puede cambiar. Lo que no cambia es el principio: antes de que el agente ejecute, alguien tiene que haber pensado qué se quiere conseguir.

No mata la velocidad. La velocidad que te dio la IA se queda. Lo que cambia es que ahora va en la dirección correcta.

Las 7 fases del flujo

Matt Pocock publicó en 2025 un video sobre su flujo de trabajo con IA — más de 250k visualizaciones — donde describió siete momentos que ocurren en cualquier proyecto serio. Independientemente de la herramienta.

Aquí están.

Fase 1: Idea

Todo empieza aquí. La trampa es ir demasiado rápido a la siguiente fase.

Tienes la idea. La entiendes en tu cabeza. Quieres empezar.

El problema: "la entiendes en tu cabeza" no significa que esté suficientemente definida para que un agente la ejecute bien. En tu cabeza hay contexto implícito, restricciones que das por sentadas, decisiones que no has tomado conscientemente.

Una pregunta para salir de la fase 1: ¿puedo describir lo que quiero en dos frases que no sean ambiguas?

Si la respuesta es no, todavía estás aquí.

Fase 2: Research (opcional)

Si hay algo desconocido en el proyecto — una API nueva, una integración que nunca hiciste — necesitas entenderlo antes de especificar.

Formato: un archivo research.md. Temporal, vive mientras dura el sprint. No es documentación permanente. Es caché.

Fase 3: Prototipo (opcional)

El prototipo ocurre antes de la spec, no después.

Si le pides al agente que construya sin haber tocado el problema primero, el agente toma todas las decisiones de diseño, de UX, de arquitectura. El resultado puede ser perfectamente funcional y completamente distinto a lo que habrías elegido tú.

El prototipo es rápido y desechable. Una vez que lo tienes, lo commiteas. La spec puede referenciarlo. Entonces sí: a especificar.

Fase 4: PRD (La spec)

El Product Requirements Document. El artefacto central de todo el método.

El PRD describe el destino, no el viaje. Qué tiene que ser verdad cuando el trabajo esté hecho. Quién lo usa. Qué puede hacer. Qué no puede hacer. Qué asumes sobre el estado actual. Qué criterios vas a usar para verificar que está hecho.

No cómo implementarlo.

Un PRD bien escrito tiene menos de 500 palabras. Si es más largo, está describiendo implementación.

Ejemplo mínimo de estructura:

## Objetivo
[Qué problema resuelve esta feature en una frase]

## Usuarios
[Quién lo usa y en qué contexto]

## Comportamiento esperado
- [El usuario puede hacer X]
- [El sistema responde con Y]
- [Cuando Z ocurre, el resultado es W]

## Fuera de scope
- [Qué NO incluye esta versión]

## Assumptions
- [Qué das por sentado sobre el estado actual del sistema]

## Criterios de aceptación
- [ ] [Verificable, concreto, testeable]
- [ ] [...]

La sección de assumptions es la que más impacto tiene en la calidad del código generado. Es también la que más gente se salta.

Fase 5: Kanban

El PRD define el destino. El kanban define el camino.

El PRD se convierte en issues. Cada issue es una unidad de trabajo que el agente puede ejecutar de forma independiente.

Dos principios para dividirlo:

Vertical slices. Cada issue implementa algo de punta a punta: interfaz, lógica, base de datos. No issues por capa. No "issue de frontend" + "issue de backend". Eso genera dependencias artificiales y hace imposible verificar hasta que todos están hechos.

Tracer bullets. Los unknowns más arriesgados van primero. Si no sabes si algo es técnicamente posible de la forma en que lo imaginaste, ese es el primer issue.

Fase 6: Execution loop

Aquí el agente toma el control.

El loop es simple: el agente lee el issue, implementa, comenta y cierra. Pasa al siguiente.

Lo que nunca es opcional: leer el código que el agente produce. No para microgestionar. Para mantener el criterio sobre lo que se está construyendo. El agente ejecuta bien. Pero tú sigues siendo el responsable del resultado.

Fase 7: QA

El trabajo está hecho. Pero no está terminado.

QA significa verificar que el comportamiento real del sistema coincide con el comportamiento especificado en el PRD. El agente puede ayudar: dale el PRD y el código y pídele que genere un plan de QA. El plan lo genera él. Las pruebas las ejecutas tú.

Los bugs y las inconsistencias que encuentres se convierten en nuevos issues. Vuelven a la fase 6.

El flujo en una imagen

IDEA
  └─ ¿Está suficientemente definida?

RESEARCH (si aplica)
  └─ research.md — caché temporal de lo desconocido

PROTOTIPO (si aplica)
  └─ Exploración rápida, desechable — commitear como referencia

PRD
  └─ Destino, no viaje
  └─ Máx. ~500 palabras — criterios de aceptación testeables

KANBAN
  └─ Vertical slices — tracer bullets primero
  └─ Blocking relationships — dependencias explícitas

EXECUTION LOOP
  └─ Agente ejecuta issue por issue
  └─ Humano lee el código producido

QA
  └─ Agente genera el plan — humano ejecuta
  └─ Bugs → nuevos issues → vuelve al loop

Por qué ahora

Thoughtworks, en su radar tecnológico de 2025, describió SDD como "una de las prácticas más importantes que emergieron con la IA generativa."

GitHub SpecKit tiene más de 72.000 estrellas y soporte para más de veinte plataformas: Claude Code, GitHub Copilot, Amazon Q, Gemini CLI. No es un proyecto de nicho. Es infraestructura.

¿Por qué importa ahora y no antes?

Porque antes, las specs las leían desarrolladores humanos. Un desarrollador puede llenar huecos, hacer preguntas, pedir aclaraciones.

Un agente no puede. Un agente rellena los huecos con lo que le parece más probable.

Y lo que le parece más probable no siempre es lo que tú querías.

Cuando el ejecutor es una IA, la calidad de las instrucciones importa más que nunca. SDD es la respuesta a eso.

Para empezar hoy

Tengo una plantilla gratuita de PRD que puedes usar en tu próximo proyecto. Incluye la estructura completa, ejemplos de criterios de aceptación y la sección de assumptions que la mayoría se salta.

👉 dominicode.com/spec-driven-development

Bezael — DominiCode

Tu app de vibe coding funciona. Eso es exactamente el problema.

Bezael Pérez — Wed, 08 Apr 2026 16:20:17 +0000

Tu app funciona.

La abriste en el navegador. Hiciste clic en los botones. Todo responde.

Hiciste el deploy. Nadie se quejó.

Y ahí está el problema.

Porque "funciona" no significa lo mismo que "está bien". Y cuando le delegas el código a una IA sin revisarlo, la diferencia entre los dos puede ser un endpoint sin autenticación, un token JWT que no expira nunca, o una contraseña guardada en texto plano en tu base de datos.

No porque la IA sea mala. Sino porque la IA optimiza para "hacer que funcione el prompt". No para "hacer que sea seguro en producción".

Lo que la IA no te dice cuando genera tu código

La IA generó tu endpoint. Lo probaste con Postman. Devolvió 200.

Pero no te dijo que cualquier usuario autenticado puede acceder a los datos de cualquier otro usuario simplemente cambiando el ID en la URL.

La IA configuró tu autenticación con JWT. Los tokens se generan. Los usuarios entran.

Pero no te dijo que esos tokens no tienen fecha de expiración. Que si uno se filtra, es válido para siempre.

La IA puso CORS para que el frontend pudiera llamar al backend.

Pero no te dijo que lo configuró con origin: '*'. Que eso significa que cualquier dominio del mundo puede hacer peticiones a tu API.

Esto no es teoría. Es lo que aparece cuando auditas una app de vibe coding. Una tras otra.

`/vibe-audit` — 30 segundos para saber en qué lío estás

Construí AI Workflow Kit porque me cansé de revisar código generado por IA de manera manual y encontrar los mismos 20 problemas cada vez.

La instalación:

npx ai-workflow-kit

Y luego, en cualquier proyecto:

/vibe-audit

Eso es todo. La skill escanea el proyecto completo, lee los archivos más críticos, y genera un reporte con severidad, evidencia concreta y el fix sugerido.

No te dice "hay un problema de seguridad". Te dice exactamente dónde está, qué línea, qué puede pasar si no lo arreglas, y cómo arreglarlo.

Los problemas que encuentra. Siempre.

Después de auditar decenas de apps generadas con IA, hay 20 patrones que aparecen una y otra vez. Estos son los más comunes:

Los críticos — los que pueden costarte el proyecto:

Secretos hardcodeados. La IA pone API keys, contraseñas y URLs de base de datos directamente en el código porque "funciona más rápido en el prompt". Aparece en casi el 100% de los proyectos generados sin revisión.

// Lo que encuentras
OPENAI_API_KEY = "sk-..."
password: "admin123"
const SECRET = "abc123"

Sin validación de inputs. Los endpoints confían ciegamente en req.body. Cualquier usuario puede mandarte lo que quiera. Incluyendo role: "admin".

const { email, role } = req.body
await db.users.update({ role })  // el usuario se da a sí mismo rol de admin

IDOR — acceso a recursos de otros usuarios. El endpoint GET /api/orders/:id no verifica que ese pedido sea tuyo. Cambia el número en la URL. Accedes a los datos de cualquier otro usuario.

Contraseñas sin hashear. No siempre. Pero ocurre, especialmente cuando el prompt fue vago o rápido.

JWT sin expiración. jwt.sign(payload, secret) sin expiresIn. Token válido para siempre. Si se filtra — en logs, en localStorage, en cualquier sitio — el atacante tiene acceso permanente.

Stack traces expuestos al cliente. res.json({ error: err.stack }) en el manejador de errores. En producción esto le da al atacante rutas internas, versiones de librerías y lógica de la aplicación.

Los importantes — los que te explotan en producción:

Queries sin paginación. db.findMany() sin límite. En desarrollo con 10 registros, perfecto. En producción con 50.000, la base de datos se cae.

APIs de terceros sin rate limiting. La IA conecta tu app a OpenAI, Stripe, o cualquier API externa y llama directamente sin control. Un bot puede hacer miles de llamadas y arruinarte la factura o hacer que el proveedor banee tu cuenta.

Sin estados de loading o error en el frontend. La IA genera el happy path perfecto. Si la API tarda o falla, la app se queda en blanco o explota en silencio.

console.logs de desarrollo en producción. La IA logea todo para depurar. Esos logs exponen datos internos y contaminan los logs de producción.

El reporte que genera /vibe-audit tiene este formato:

# Vibe Audit — nombre-del-proyecto
Auditado: fecha

## Resumen
- 🔴 Críticos: N  (bloquear producción o son riesgos de seguridad)
- 🟡 Importantes: N (afectan estabilidad o mantenibilidad)
- 🔵 Mejoras: N   (deuda técnica, calidad)

## 🔴 Críticos

### Contraseñas sin hashear
**Dónde:** `src/auth/register.ts` línea 23
**Evidencia:**
[código problemático]
**Riesgo:** Si la base de datos se compromete, todas las contraseñas quedan expuestas en texto plano
**Fix sugerido:**
[código corregido]

No generalidades. Código concreto. Línea exacta. Fix aplicable.

El resto del kit

/vibe-audit es la razón de ser del kit. Pero no está solo.

Una vez que tu app está auditada y los problemas críticos resueltos, el workflow se mantiene limpio con el resto de las herramientas:

Skills:

/commit — lee el diff real y genera un commit semántico. Sin copy-paste, sin "fix stuff"
/pr — PR con descripción, plan de tests y checklist de revisión
/review @archivo — revisa bugs, seguridad y rendimiento con criterios de ingeniería real
/plan [tarea] — fuerza planificación antes de ejecutar. Para tareas complejas, un plan aprobado vale más que código rápido
/debug [problema] — diagnóstico con hipótesis antes de proponer fixes

Agentes especializados:

/frontend — componentes siguiendo el sistema de diseño del proyecto
/api — endpoints con validación, auth y manejo de errores
/test — tests por comportamiento, no por implementación
/refactor — mejora el código sin cambiar el comportamiento
/docs — JSDoc, README, ADR según el contexto

Hooks automáticos — sin activación, corren solos:

Bloquea comandos destructivos antes de que se ejecuten
Escanea archivos staged buscando API keys antes de cada commit
Formatea con Prettier o Biome después de cada edición
Corre ESLint y devuelve los errores a Claude para que los corrija
Notificación de escritorio cuando Claude termina (Mac/Linux/Windows)

Funciona con Claude Code, Cursor y GitHub Copilot.

La diferencia entre vibe coding y vibe coding bien hecho

El vibe coding no va a desaparecer. Ni debería.

La velocidad es real. La productividad es real. Poder construir en horas lo que antes tardaba días es real.

El problema no es la velocidad. El problema es confundir "rápido" con "hecho".

Tu app necesita los dos. Velocidad para llegar al mercado. Y un /vibe-audit para saber qué hay dentro antes de que alguien más lo descubra por ti.

Una línea:

npx ai-workflow-kit

GitHub: https://github.com/bezael/ai-workflow-kit

Your vibe coding app works. That's exactly the problem.

Bezael Pérez — Wed, 08 Apr 2026 16:20:02 +0000

Your app works.

You opened it in the browser. Clicked the buttons. Everything responds.

You deployed it. Nobody complained.

And that's exactly the problem.

Because "works" doesn't mean the same thing as "is correct". And when you delegate code to an AI without reviewing it, the gap between those two can be an endpoint with no authentication, a JWT token that never expires, or a password stored in plaintext in your database.

Not because the AI is bad. But because the AI optimizes for "make the prompt work". Not for "make it safe in production".

What the AI doesn't tell you when it generates your code

The AI generated your endpoint. You tested it with Postman. It returned 200.

But it didn't tell you that any authenticated user can access any other user's data just by changing the ID in the URL.

The AI set up your JWT authentication. Tokens are generated. Users log in.

But it didn't tell you those tokens have no expiration date. That if one leaks, it's valid forever.

The AI configured CORS so the frontend could call the backend.

But it didn't tell you it set origin: '*'. That means any domain in the world can make requests to your API.

This isn't theory. It's what shows up when you audit a vibe-coded app. Every single time.

`/vibe-audit` — 30 seconds to know what mess you're in

I built AI Workflow Kit because I got tired of manually reviewing AI-generated code and finding the same 20 problems every time.

Installation:

npx ai-workflow-kit

Then, in any project:

/vibe-audit

That's it. The skill scans the entire project, reads the most critical files, and generates a report with severity, concrete evidence, and the suggested fix.

It doesn't tell you "there's a security problem". It tells you exactly where it is, which line, what can happen if you don't fix it, and how to fix it.

The problems it finds. Every time.

After auditing dozens of AI-generated apps, there are 20 patterns that show up again and again. These are the most common:

The critical ones — the ones that can kill your project:

Hardcoded secrets. The AI puts API keys, passwords, and database URLs directly in the code because "it works faster in the prompt". Shows up in almost 100% of projects generated without review.

// What you find
OPENAI_API_KEY = "sk-..."
password: "admin123"
const SECRET = "abc123"

No input validation. Endpoints blindly trust req.body. Any user can send you whatever they want. Including role: "admin".

const { email, role } = req.body
await db.users.update({ role })  // user gives themselves admin role

IDOR — access to other users' resources. The GET /api/orders/:id endpoint doesn't verify that order belongs to you. Change the number in the URL. You access any other user's data.

Unhashed passwords. Not always. But it happens, especially when the prompt was vague or rushed.

JWT without expiration. jwt.sign(payload, secret) without expiresIn. Token valid forever. If it leaks — in logs, in localStorage, anywhere — the attacker has permanent access.

Stack traces exposed to the client. res.json({ error: err.stack }) in the error handler. In production this gives an attacker internal paths, library versions, and application logic.

The important ones — the ones that blow up in production:

Queries without pagination. db.findMany() without a limit. In development with 10 records, perfect. In production with 50,000, the database goes down.

Third-party APIs without rate limiting. The AI connects your app to OpenAI, Stripe, or any external API and calls directly with no control. A bot can fire thousands of requests and wreck your bill or get your account banned by the provider.

No loading or error states in the frontend. The AI generates the perfect happy path. If the API is slow or fails, the app goes blank or crashes silently.

Development console.logs in production. The AI logs everything for debugging. Those logs expose internal data and pollute your production logs.

The report /vibe-audit generates looks like this:

# Vibe Audit — project-name
Audited: date

## Summary
- 🔴 Critical: N  (block production or are security risks)
- 🟡 Important: N (affect stability or maintainability)
- 🔵 Improvements: N   (technical debt, quality)

## 🔴 Critical

### Unhashed passwords
**Where:** `src/auth/register.ts` line 23
**Evidence:**
[problematic code]
**Risk:** If the database is compromised, all passwords are exposed in plaintext
**Suggested fix:**
[corrected code]

No vague warnings. Concrete code. Exact line. Actionable fix.

The rest of the kit

/vibe-audit is the reason the kit exists. But it doesn't stand alone.

Once your app is audited and the critical issues resolved, the rest of the tools keep the workflow clean:

Skills:

/commit — reads the real diff and generates a semantic commit. No copy-paste, no "fix stuff"
/pr — PR with description, test plan, and reviewer checklist
/review @file — reviews bugs, security, and performance with real engineering criteria
/plan [task] — forces planning before execution. For complex tasks, an approved plan is worth more than fast code
/debug [problem] — diagnosis with hypotheses before proposing fixes

Specialized agents:

/frontend — components following the project's design system
/api — endpoints with validation, auth, and error handling
/test — behavior-driven tests, not implementation tests
/refactor — improves code without changing behavior
/docs — JSDoc, README, or ADR depending on context

Automatic hooks — no activation needed, they just run:

Blocks destructive commands before they execute
Scans staged files for API keys before every commit
Formats with Prettier or Biome after every edit
Runs ESLint and feeds errors back to Claude to fix
Desktop notification when Claude finishes (Mac/Linux/Windows)

Works with Claude Code, Cursor, and GitHub Copilot.

The difference between vibe coding and vibe coding done right

Vibe coding isn't going away. And it shouldn't.

The speed is real. The productivity is real. Being able to build in hours what used to take days is real.

The problem isn't the speed. The problem is mistaking "fast" for "done".

Your app needs both. Speed to reach the market. And a /vibe-audit to know what's inside before someone else finds out for you.

One line:

npx ai-workflow-kit

GitHub: https://github.com/bezael/ai-workflow-kit

De Senior Dev a Tech Lead: la transición donde más talento se pierde ¿Te ha pasado?

Bezael Pérez — Wed, 29 Oct 2025 18:08:40 +0000

Bezael Pérez

Oct 28 '25

Por qué los desarrolladores que pasan a tech lead fracasan…

#liderazgo #tecnologia #management

Comments

2 min read

Por qué los desarrolladores que pasan a tech lead fracasan…

Bezael Pérez — Tue, 28 Oct 2025 16:57:24 +0000

De Senior Dev a Tech Lead: la transición donde más talento se pierde

¿Te ha pasado?

Eras un desarrollador senior brillante… y un día te dicen:

“A partir de ahora, serás Tech Lead.”

Lo tomas como un ascenso.

Pero en realidad, es un cambio de profesión.

Y aquí es donde muchos (muchísimos) desarrolladores fracasan.

¿Por qué?

Porque siguen midiendo su valor con las métricas equivocadas.

El conflicto central

Tu valor ya no está en tu código.

Como Senior Dev, te valoran por tu output individual:

la calidad de tu código, lo rápido que resuelves problemas, lo bien que entregas.

Como Tech Lead, te valoran por el output de tu equipo:

rendimiento colectivo, claridad, bienestar, producto final y alineación con negocio.

El día que entiendes eso, todo cambia.

🚨 Los 5 errores más comunes (y cómo evitarlos)

1. El síndrome del héroe

“Es más rápido si lo hago yo.”

Falla: te conviertes en cuello de botella.

Solución: delega, confía y enseña. Tu trabajo ya no es escribir código, es que se escriba bien.

2. El micromanagement disfrazado de “calidad”

Code reviews de 50 comentarios, querer aprobarlo todo.

Falla: ahogas la autonomía del equipo.

Solución: define estándares, automatiza lo repetitivo y revisa lo que realmente importa.

3. Falla de comunicación

“Pero si técnicamente es obvio…”

Falla: olvidas que no todos hablan tu idioma.

Solución: traduce el lenguaje técnico al de negocio y viceversa. El contexto es poder.

4. Olvidar el factor humano

Tu equipo no son tickets en Jira.

Solución: haz 1:1, pregunta cómo están, protege su foco y reconoce sus logros.

5. Seguir queriendo ser el mejor programador

Solución: recalibra tu éxito.

Ya no eres el más rápido, eres quien hace que los demás lleguen más lejos.

💡 En resumen

Pasar a Tech Lead no es subir un peldaño, es cambiar de escalera.

Dejas de ser un doer para convertirte en un facilitador.

Un multiplicador de fuerza.

Si lo haces bien, tu impacto se multiplica.

Si no, acabarás quemado… y tu equipo también.

📘 Estoy preparando una guía completa sobre “Cómo no fracasar en la transición de Senior Dev a Tech Lead”, con ejemplos y prompts de IA para cada reto.

¿Te gustaría que la comparta en PDF gratis cuando esté lista?

Jest 30: Más Rápido, Inteligente y Listo para el Futuro. ¿Es Hora de Actualizar?

Bezael Pérez — Thu, 26 Jun 2025 05:51:57 +0000

Después de una espera que pareció una eternidad en el vertiginoso mundo del desarrollo de software, el equipo de Jest ha lanzado la versión 30. Y permíteme decirte, la espera ha valido la pena. Esto no es una simple actualización incremental; es una reinvención fundamental que aborda deudas técnicas de larga data, responde a las críticas de la comunidad y reafirma a Jest como un titán en el panorama de las pruebas de JavaScript.

Durante años, los desarrolladores hemos tenido una relación de amor-odio con Jest. Adoramos su simplicidad de "cero configuración" y su potente ecosistema, pero a menudo nos hemos enfrentado a tiempos de ejecución lentos y a un consumo de memoria descontrolado en proyectos grandes. Jest 30 no solo pule los bordes ásperos, sino que reconstruye los cimientos.

¿Por qué esta actualización es un punto de inflexión?

Adiós a la Lentitud

El problema más notorio de Jest siempre ha sido el rendimiento. La versión 30 ataca este problema en dos frentes con una eficacia brutal:

Módulos Ultrarrápidos:

El principal cuello de botella era la forma en que Jest encontraba los módulos. En proyectos grandes, especialmente monorepos, la búsqueda recursiva de archivos package.json consumía una cantidad desproporcionada de tiempo. Jest 30 reemplaza este sistema con unrs-resolver, un nuevo componente de alto rendimiento que aprovecha la velocidad de Rust.

Resultados: Los benchmarks oficiales muestran tiempos de ejecución hasta un 37% más rápidos en aplicaciones TypeScript de gran tamaño.
Control de Fugas de Memoria:

¿Quién no ha visto fallar su pipeline de CI por un misterioso error de "heap out of memory"? Jest 30 introduce una solución nativa con la opción globalsCleanup. Esta característica detecta y limpia automáticamente las variables globales que se "filtran" entre pruebas, una de las principales causas de las fugas de memoria.

En el mismo benchmark, esta opción redujo el uso máximo de memoria en un increíble 77% (de 7.8 GB a 1.8 GB).

Esto no es una optimización, es un cambio radical que puede estabilizar por completo tus pruebas.

Nuevas Herramientas para el Desarrollador

Más allá de la velocidad, Jest 30 enriquece nuestra caja de herramientas con funcionalidades que simplifican patrones de prueba comunes y mejoran la legibilidad del código.

expect.arrayOf(matcher): Una de las adiciones más solicitadas. Ahora puedes verificar que cada elemento de un array cumple con un matcher específico de forma declarativa, sin necesidad de bucles manuales.

  // Verifica que cada objeto en el array tiene un 'id' de tipo string.
  expect(users).toEqual(expect.arrayOf(
    expect.objectContaining({ id: expect.any(String) })
  ));

using spy para una Gestión de Mocks Impecable: Aprovechando la nueva sintaxis de "Explicit Resource Management" de JavaScript, ahora podemos crear espías que se restauran automáticamente al salir del ámbito. ¡Adiós a los olvidos de mockRestore() en los bloques afterEach!

  test('llama a console.warn', () => {
    // El espía se restaura automáticamente al final del test. ¡Magia!
    using consoleWarnSpy = jest.spyOn(console, 'warn').mockImplementation(() => {});

    console.warn('un aviso');
    expect(consoleWarnSpy).toHaveBeenCalled();
  });

Reintentos de Pruebas Configurables: Las pruebas inestables (flaky tests) son la pesadilla de la integración continua. jest.retryTimes() ahora permite configurar un retardo entre reintentos (waitBeforeRetry) o reintentar una prueba fallida de inmediato (retryImmediately), dándote un control mucho más fino.

La Migración: ¿Vale la Pena el Esfuerzo?

Seamos claros: Jest 30 introduce cambios rompedores. Requiere Node.js 18+ y TypeScript 5.4+, y elimina los alias de matchers obsoletos (como toBeCalled en lugar de toHaveBeenCalled).

Sin embargo, la migración es más sencilla de lo que parece. La mayoría de los cambios de alias se pueden solucionar automáticamente con eslint-plugin-jest. El esfuerzo de actualizar es una inversión directa en una base de código de pruebas más moderna, robusta y, sobre todo, más rápida.

El Futuro de las Pruebas y Cómo Dominarlo

Esta actualización demuestra que Jest no solo está vivo, sino que está evolucionando para liderar la próxima era de las pruebas en JavaScript. Escribir pruebas no es solo una formalidad; es un arte que, cuando se domina, garantiza la calidad y la mantenibilidad de nuestras aplicaciones.

Si estas mejoras en Jest 30 te inspiran a llevar tus pruebas al siguiente nivel, especialmente en el ecosistema de Angular, he volcado años de experiencia en mi libro: Unit testing con Jest y Testing Library en Angular.

Es la guía perfecta para dominar no solo las herramientas, sino las estrategias para escribir pruebas que realmente aporten valor y confianza a tu equipo.

Las pruebas unitarias son la base de una pirámide de software sólida. Para una inmersión profunda en patrones prácticos, ejemplos del mundo real y cómo aprovechar al máximo herramientas como Jest y Testing Library, puedes encontrar más información y adquirir el libro aquí

Conclusión: Un Nuevo Comienzo para Jest

Jest 30 es una declaración de intenciones. Es una respuesta contundente a las alternativas modernas y una promesa de un futuro con ciclos de lanzamiento más consistentes y un desarrollo más audaz. Las mejoras de rendimiento son reales y tangibles, las nuevas funcionalidades son ergonómicas y potentes, y la hoja de ruta es clara.

Si has estado luchando con la lentitud de Jest o te has sentido tentado por otras herramientas, esta es la actualización que estabas esperando. Es el momento de actualizar, explorar las nuevas funcionalidades y llevar tus pruebas a un nuevo nivel de eficiencia y fiabilidad.

El futuro de las pruebas con Jest es brillante.

De Jasmine a Jest: Migración sin dolor en 30 minutos

Bezael Pérez — Sun, 15 Jun 2025 19:36:36 +0000

¿Te imaginas recortar a la mitad el tiempo que tardan tus pruebas de Angular con un simple giro de tuercas que casi nadie está aplicando todavía?
Hoy vas a descubrir cómo hacerlo y por qué aplazarlo podría costarte horas de café frío y deploys retrasados.

La verdad incómoda sobre Karma

Karma ha sido el “motor” oficial durante años.
Pero en Angular 16 ya apareció en la lista de obsoletos y, desde la versión 17, vive con fecha de caducidad impresa.
Cada lanzamiento de navegador, cada reconexión y cada pestaña oculta que se abre en segundo plano es un ladrillo más en la pared que separa tu código de la luz verde del pipeline.

Por qué Jest está ganando terreno en silencio

Jest no necesita un navegador real para ejecutar tests: todo sucede en memoria, como quien hace cálculos sobre la servilleta del bar.
Los informes son legibles, coloreados y te señalan el error con una flecha casi insultante.
Además, el caché inteligente evita repetir trabajo y acelera aún más cada iteración.
La comunidad ya lo adoptó; el propio equipo de Angular lo reconoce como la opción a futuro. ¿Vas a quedarte fuera?

Tu plan exprés de 30 minutos

Actualiza dependencias
Añade el preset oficial de Angular para Jest y retira los paquetes de Karma. Con una sola orden de instalación limpias el terreno.
Prepara la configuración
Reemplaza el archivo de Karma por el de Jest. Solo necesitas declarar el preset, el directorio de cobertura y los mapeos de paths que ya usas.
Adapta los setup files
Si inicializabas zonas o polyfills especiales, muévelos al archivo de arranque de Jest. El formato cambia, pero el contenido es prácticamente el mismo.
Ajusta los test utilities
TestBed sigue funcionando; la diferencia es que las utilidades de Jest —spies, temporizadores falsos, snapshots— sustituyen a las de Jasmine sin dolor.
Corre la primera pasada
Ejecuta tus pruebas. Lo habitual es ver una ráfaga verde y un tiempo de ejecución que parece un error de imprenta: tan rápido que querrás presumir la captura.

Lo que nadie te cuenta (pero necesitas saber)

Cobertura instantánea: Jest muestra el porcentaje de líneas cubiertas sin plugins extra.
Migración incremental: puedes mantener algunos archivos en Jasmine mientras terminas la transición.
Integración continua simplificada: adiós a los launchers de navegador y a esa configuración críptica que nunca recuerdas.

¿Qué pasa si lo dejas para mañana?

Karma desaparecerá del CLI y tendrás que migrar deprisa, bajo presión y con todo el equipo mirando el reloj.
El coste no será solo técnico: cada minuto de espera en cada build se multiplicará por cada desarrollador y cada pull request.

Da el salto ahora mismo

Haz clic aquí y descarga el ebook “Unit testing con Jest y Testing Library en Angular”.
Y tendrás tu proyecto corriendo con Jest y disfrutarás de test suites que vuelan.

Recuerda el beneficio final

Migrar hoy significa ciclos de feedback rapidísimos, menos frustración y más tiempo para crear funcionalidades que importan.
No dejes que un runner obsoleto decida tu velocidad de desarrollo: adopta Jest y comprueba cómo tus pruebas dejan de ser un lastre para convertirse en tu mejor aliado.

Paso 1 – Instala lo esencial sin perder un minuto

Abre tu terminal favorita y ejecuta el gestor de paquetes para añadir Jest, jest-preset-angular y @types/jest como dependencias de desarrollo.
Con esta sola acción dejas listo el motor, el adaptador específico para Angular y las definiciones de tipos que evitarán errores de compilación más adelante.

Confirma al terminar que el archivo de bloqueos (ya sea package-lock.json o pnpm-lock.yaml) refleje las tres librerías; eso te garantiza entornos reproducibles en todo el equipo.

¿Listo? En menos de lo que tarda en hervir el café, ya tienes las bases instaladas y puedes pasar al siguiente ajuste de configuración.

npm install --save-dev jest jest-preset-angular @types/jest
# o si usas yarn
yarn add --dev jest jest-preset-angular @types/jest

2. Ajuste del `package.json`

Imagina que el corazón de tu proyecto late en el package.json.
El próximo latido –el que activará Jest– se cocina con un simple ajuste.

Abre ese archivo y localiza el bloque scripts.
Dentro verás la orden clásica que dispara Karma; bórrala sin piedad.

En su lugar, coloca una instrucción que invoque Jest de forma directa, sin corredores intermedios ni arranques de navegador.

Con esta única sustitución, cada vez que escribas npm run test (o el alias que uses) entrarás en la nueva era de tests turboalimentados.

Guarda el cambio, ejecuta la prueba… y comprueba cómo el cronómetro se hunde: tu suite ahora corre a la velocidad que siempre quisiste.

{
  "scripts": {
    "test": "npx jest"
  }
}

3. Configuración de `tsconfig.spec.json`

¿Todavía ves el fantasma de Jasmine acechando en tu tsconfig.spec.json?
Ese pequeño detalle frena a TypeScript y puede hacer que tus imports de Jest luzcan como errores.

Localiza la puerta de entrada
Abre tsconfig.spec.json y busca la propiedad types dentro de compilerOptions. Allí es donde “vive” la referencia a los tipos globales que entiende el compilador.
Expulsa al huésped equivocado
Si la lista contiene "jasmine", sustitúyelo por "jest". Puedes mantener otras entradas útiles (por ejemplo, "node") si ya estaban presentes: la regla es dejar solo el conjunto de tipos que realmente necesitas.
Guarda y respira
A partir de este cambio, TypeScript reconocerá todas las funciones globales de Jest (describe, it, expect, etc.) sin que necesites imports extra ni comentarios de bypass. Un simple npm run test confirmará que las advertencias desaparecieron y que tu nueva configuración late con normalidad.

Con esa edición mínima habrás desalojado por completo los viejos tipos de Jasmine y tu proyecto quedará afinado para el nuevo corredor de pruebas.

¿Listo para el siguiente ajuste o hay algo que quieras pulir antes de continuar?

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["jest", "node"] // Cambia "jasmine" por "jest"
  },
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}

4. Creación de `jest.config.ts`

¿Preparado para darle a Jest las llaves de tu proyecto?

Crea el archivo
En la raíz, añade un nuevo jest.config.ts. Piensa en él como la consola central desde la que controlarás cada test.
Importa el preset oficial
El primer paso dentro del archivo es “enchufar” jest-preset-angular. Con eso, Jest entenderá componentes, pipes y templates como si llevara años hablando Angular.
Define la configuración

preset: apunta a 'jest-preset-angular'.
testEnvironment: usa 'jsdom' para una simulación ligera de navegador.
setupFilesAfterEnv: referencia a un pequeño jest.setup.ts donde inicialices jest-preset-angular, fakeAsync zones o utilidades globales.
transform: indica a Jest que los archivos .ts y .html pasen por el transformador que trae el preset.
moduleNameMapper: replica aquí los alias de paths que ya tienes en tu tsconfig, de modo que los imports sigan funcionando.
coverageDirectory: elige la carpeta donde quieras el informe de cobertura; así mantienes los resultados fuera de la carpeta de artefactos principales.
transformIgnorePatterns: excluye el código de terceros (por ejemplo, node_modules/(?!(lodash-es|rxjs))) si necesitas transpilar alguna librería moderna.

Guarda y prueba Con solo ese puñado de líneas, Jest sabe exactamente cómo arrancar tus specs de Angular. Lanza npm run test y observa cómo se disparan los resultados: rápido, limpio y con un informe de cobertura listo para presumir.

Sin tocar una sola línea de tu código de producción, habrás levantado la nueva central de mando para tus pruebas unitarias. Tu stack ya funciona con Jest; lo siguiente es disfrutar de ciclos de feedback que casi no dan tiempo ni a parpadear.

import type { Config } from 'jest';

const config: Config = {
  preset: 'jest-preset-angular',
  setupFilesAfterEnv: ['<rootDir>/setup-jest.ts'],
  moduleDirectories: ['node_modules', '<rootDir>'],
  testMatch: ['**/+(*.)+(spec).+(ts)'],
};

export default config;

5. Creación de `setup-jest.ts`

¿Sabías que un único archivo puede convocar todo el poder de Jest y al mismo tiempo convencer a Angular de que nada ha cambiado? Ese archivo se llama setup-jest.ts, y su misión es dejar listo el escenario antes de que se ejecute la primera prueba.

Por qué importa

Jest necesita que le cuentes cómo funcionan las zonas de Angular, cómo compilar plantillas y en qué momento «pinchar» el TestBed. Sin esa preparación, tus components quedarían mudos y tus pipes perderían la voz.

Lo que debe ocurrir dentro

Encendido del preset
El archivo arranca cargando la utilería que traduce internamente los decoradores, las plantillas y las dependencias que Angular usa de forma nativa.
Parches y polyfills opcionales
Si tu app depende de APIs del navegador que JSDOM no expone por defecto—como matchMedia o ciertas animaciones—, aquí añades los parches mínimos para que Jest no tropiece.
Extensiones a las expectativas
Puedes incorporar ayudas de aserción adicionales—por ejemplo, comparadores de fechas o números aproximados—sin repetir imports en cada archivo de prueba.
Configuración global de tiempo
Ajustar un timeout genérico evita que las pruebas se queden colgadas por operaciones lentas, manteniendo el reporte limpio y controlado.

Con esa coreografía, cada spec encuentra un Angular completamente operativo en milésimas de segundo, sin demoras ni advertencias extrañas. Guarda el archivo junto al resto de tu código y lánzate a ejecutar npm run test: verás cómo todo fluye con la seguridad de saber que tu entorno está perfectamente preparado antes de que el cronómetro arranque.

import 'jest-preset-angular/setup-jest';
import '@angular/localize/init'; // Necesario para Angular >= 9
// Workaround para ReferenceError: TextEncoder is not defined en Jest
import { TextEncoder } from 'node:util';
Object.defineProperty(window, 'TextEncoder', {
  writable: true,
  value: TextEncoder,
});

6. Deja atrás el lastre de Karma y Jasmine

Ahora que tu suite vuela con Jest, mantener las viejas dependencias es como llevar un ancla colgada al tobillo. Deshazte de Karma, Jasmine y cualquier launcher o reporter relacionado: liberarás espacio, acelerarás las instalaciones de CI y evitarás conflictos de versiones en el futuro.

Depuración del package.json
Despídete de cada librería que empiece por karma- o jasmine-. Al retirarlas, tu árbol de dependencias se encoge y las descargas en cada pipeline se reducen a la mitad.
Limpieza de archivos de configuración
Borra karma.conf.js, test.ts (si lo tienes) y cualquier script de npm que invoque Karma. Si tu CI aún abre un navegador para los tests, elimínalo también: ese paso dejó de tener sentido.
Revisión de scripts y tasks
Comprueba que no queden comandos heredados en la carpeta de herramientas, ni pasos de build que referencien al viejo runner. Una búsqueda rápida por el repositorio te dará la certeza.
Actualización del cache de CI
Sin Karma ni Chrome Headless en la ecuación, tu contenedor construirá menos capas y completará los tests antes de que acabes el primer sorbo de café.
Confirmación final
Ejecuta la suite con Jest en local y en la pipeline. Verás cómo la lista de paquetes descargados se acorta y los tiempos de ejecución marcan nuevos mínimos históricos.

Con esta purga, tu proyecto queda más ligero, tu presupuesto de CI respira y tu equipo trabaja sobre un stack coherente y enfocado en el futuro. Sigue avanzando; cada archivo antiguo que eliminas es un segundo menos de espera en tu próximo deploy.

npm uninstall karma karma-chrome-launcher karma-jasmine karma-coverage karma-jasmine-html-reporter @types/jasmine @types/jasminewd2 jasmine-core jasmine-spec-reporter

Ejemplo mínimo: Conversión de una prueba tradicional a Jest con Testing Library

Veamos un ejemplo sencillo de cómo se vería una prueba antes y después de la migración.

Componente CounterComponent (ejemplo):

// counter.component.ts
import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <button (click)="decrement()">-</button>
    <span data-testid="count">{{ count() }}</span>
    <button (click)="increment()">+</button>
  `,
  standalone: true,
})
export class CounterComponent {
  count = signal(0);

  increment() {
    this.count.update((value) => value + 1);
  }

  decrement() {
    this.count.update((value) => value - 1);
  }
}

Prueba tradicional (Karma/Jasmine con TestBed):

// counter.component.spec.ts (Antes)
import { ComponentFixture, TestBed } from '@angular/core/testing';
import { CounterComponent } from './counter.component';

describe('CounterComponent', () => {
  let component: CounterComponent;
  let fixture: ComponentFixture<CounterComponent>;
  let compiled: HTMLElement;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CounterComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(CounterComponent);

    component = fixture.componentInstance;
    compiled = fixture.nativeElement;
    fixture.detectChanges();
  });

  it('Haves an initial count of 0', () => {
    expect(component.count()).toBe(0);
  });

  it('Renders the initial count of 0 in the span', () => {
    const countSpan = compiled.querySelector('[data-testid="count"]');
    expect(countSpan?.textContent).toBe('0');
  });

  it('Increment the count signal when increment() is called', () => {
    expect(component.count()).toBe(0);

    component.increment();
    expect(component.count()).toBe(1);
  });

  it('Decrement the count signal when decrement() is called', () => {
    expect(component.count()).toBe(0);

    component.decrement();

    expect(component.count()).toBe(-1);
  });

  it('Increment the count in the template when the "+" button is clicked', () => {
    const incrementButton = compiled.querySelectorAll('button')[1];
    const countSpan = compiled.querySelector('[data-testid="count"]');

    incrementButton.click();
    fixture.detectChanges();

    expect(component.count()).toBe(1);
    expect(countSpan?.textContent).toBe('1');
  });

  it('Decrement the count in the template when the "-" button is clicked', () => {
    const decrementButton = compiled.querySelector('button');
    const countSpan = compiled.querySelector('[data-testid="count"]');

    expect(countSpan?.textContent).toBe('0');

    decrementButton?.click();
    fixture.detectChanges();

    expect(component.count()).toBe(-1);
    expect(countSpan?.textContent).toBe('-1');
  });
});

Prueba migrada (Jest):

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { CounterComponent } from './counter.component';

describe('CounterComponent (con Jest) - Versión Mejorada', () => {
  let component: CounterComponent;
  let fixture: ComponentFixture<CounterComponent>;
  let compiled: HTMLElement;

  const getElement = (selector: string): HTMLElement | null => compiled.querySelector(selector);
  const getButton = (text: string): HTMLButtonElement | null => {
    return Array.from(compiled.querySelectorAll('button')).find((btn) => btn.textContent === text) || null;
  };
  const getCountSpan = (): HTMLElement | null => getElement('[data-testid="count"]');

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [CounterComponent],
    }).compileComponents();

    fixture = TestBed.createComponent(CounterComponent);
    component = fixture.componentInstance;
    compiled = fixture.nativeElement;
    fixture.detectChanges();
  });

  describe('Initial State and Rendering', () => {
    it('Initialize with a count of 0', () => {
      expect(component.count()).toBe(0);
    });

    it('Renders the initial count "0" inside the span', () => {
      const countSpan = getCountSpan();
      expect(countSpan).not.toBeNull();
      expect(countSpan?.textContent).toBe('0');
    });

    it('Renders an increment and a decrement button', () => {
      const incrementButton = getButton('+');
      const decrementButton = getButton('-');
      expect(incrementButton).not.toBeNull();
      expect(decrementButton).not.toBeNull();
    });
  });

  describe('Business Logic', () => {
    it('Update the count signal from 0 to 1', () => {
      component.increment();
      expect(component.count()).toBe(1);
    });

    it('Update the count signal from 0 to -1', () => {
      component.decrement();
      expect(component.count()).toBe(-1);
    });

    it('Handles multiple operations correctly (e.g., increment twice, decrement once)', () => {
      component.increment();
      component.increment();
      component.decrement();
      expect(component.count()).toBe(1);
    });
  });

  describe('User Interaction', () => {
    it('Update the displayed count to "1" when the "+" button is clicked', () => {
      const incrementButton = getButton('+');
      incrementButton?.click();
      fixture.detectChanges();

      const countSpan = getCountSpan();
      expect(component.count()).toBe(1);
      expect(countSpan?.textContent).toBe('1');
    });

    it('Update the displayed count to "-1" when the "-" button is clicked', () => {
      const decrementButton = getButton('-');
      decrementButton?.click();
      fixture.detectChanges();

      const countSpan = getCountSpan();
      expect(component.count()).toBe(-1);
      expect(countSpan?.textContent).toBe('-1');
    });

    it('Displays "0" after clicking "+" and then "-"', () => {
      const incrementButton = getButton('+');
      const decrementButton = getButton('-');

      incrementButton?.click();
      fixture.detectChanges();

      decrementButton?.click();
      fixture.detectChanges();

      const countSpan = getCountSpan();
      expect(component.count()).toBe(0);
      expect(countSpan?.textContent).toBe('0');
    });
  });
});

¿Lo mejor de todo? Ahora tu archivo de pruebas no solo “pasa”, sino que respira mantenimiento futuro.

Por qué tus ajustes son oro puro

Selectores resilientes
Buscar por texto (+ / −) anula la fragilidad del índice numérico. Mañana podrás insertar un botón “reset” en cualquier parte y el test ni se despeinará.
Describe anidados que cuentan una historia
Al separar Estado Inicial, Lógica y Interacción, cualquiera localiza la intención en segundos. Leer el archivo deja de ser un safari de it() sueltos y pasa a ser un mapa bien señalizado.
Helpers DRY
Centralizar la obtención de elementos reduce el “ruido” en cada spec y concentra el cambio en un único punto. Si algún día migras de data-testid a atributos ARIA, actualizarás solo esas funciones.
Cobertura real de flujos
Verificar la presencia de ambos botones y la secuencia + → − garantiza que tu contador no falla ante combinaciones encadenadas. Es un test de comportamiento, no una foto estática.

Cómo exprimir aún más tu nueva base

Añade tests de accesibilidad
Usa jest-axe para asegurarte de que los cambios visuales no rompen reglas WCAG. Mantendrás al equipo en verde respecto a inclusión sin esfuerzo manual.
Integra snapshots selectivos
Útiles para componentes con mucho markup. Hazlo solo en piezas poco volátiles; así evitarás falsas alarmas en cada refactor visual menor.
Mide la cobertura de ramas
Activa coverageReporters: ['text', 'lcov'] y revisa los puntos ciegos. Verás con claridad qué caminos lógicos no pisan todavía tus pruebas.
Optimiza los fake timers
Para lógica basada en setTimeout o debounce, los temporizadores controlados de Jest aceleran las specs y evitan esperas innecesarias.
Revisa tu pipeline de CI
Ahora que Karma salió de escena, ajusta el caché de dependencias y elimina pasos de navegador. Ganas minutos en cada ejecución automática.

Has sentado un cimiento robusto: pruebas legibles, resistentes y fáciles de ampliar. A partir de aquí, cualquier nueva funcionalidad se incorporará con confianza y sin temer al efecto dominó.

Bonus: Jest y Angular Testing Library

¿Listo para ver cómo el mismo test respira libertad sin fixture, sin detectChanges() y sin ese ruido que encoge la vista?

Observa esta versión con Angular Testing Library: minimalista, robusta y pensada para el futuro.

Prueba migrada (Jest y Angular Testing Library):

// counter.component.spec.ts (Después)
import { render, screen, fireEvent } from '@testing-library/angular';
import { CounterComponent } from './counter.component';
import '@testing-library/jest-dom'; // Para matchers extendidos como.toBeInTheDocument()

describe('CounterComponent (Jest/Testing Library)', () => {
  // Helper centralizado: un solo punto de cambio
  const setup = async () => {
    await render(CounterComponent); // crea componente + fixture por ti
    const getButton = (label: string) => screen.getByRole('button', { name: label });
    return {
      getCount: () => screen.getByTestId('count'),
      getButton,
    };
  };

  it('Create and display initial count of 0', async () => {
    const { getCount } = await setup();
    expect(getCount()).toHaveTextContent('0');
  });

  it('Increment count when + button is clicked', async () => {
    const { getButton, getCount } = await setup();
    fireEvent.click(getButton('+'));

    expect(getCount()).toHaveTextContent('1');
  });

  it('Decrement count when - button is clicked', async () => {
    const { getButton, getCount } = await setup();
    fireEvent.click(getButton('-'));
    expect(getCount()).toHaveTextContent('-1');
  });
});

Sin fixtures ni TestBed.compileComponents(). render() hace la magia tras bambalinas.
Selectores accesibles (getByRole): resistentes a cambios de orden o estilo.
Flujos síncronos por defecto: cuando algo sea realmente asíncrono, usa await waitFor(() => …) y listo.

¿Te gustó la sensación de limpieza? En mi libro sobre testing moderno en Angular, profundizo en querying accesible, patrones de state observers y prácticas de rendimiento que hacen que tus tests vuelen.

¿Prefieres aprender mirando? Aquí tienes tu atajo visual

Sé que la instalación de Angular Testing Library merece un tutorial aparte; lo verás detallado en el próximo artículo.

Mientras tanto, si eres de los que absorben conceptos viendo cada clic en tiempo real, he preparado un vídeo exprés donde compruebas, paso a paso, cómo escribir un unit test de un input required con Jest.

▶️ *Ver el vídeo en YouTube *

Beneficios medibles: Tiempo de ejecución y reporte de cobertura

En pocas líneas:

Velocidad a otro nivel
Jest ejecuta tests en paralelo y en JSDOM; suites que tardaban 15 min con Karma pueden bajar a 1-2 min.
Cobertura con un flag
jest --coverage genera informes detallados sin plugins extra, así ves al instante qué ramas faltan por probar.
Mocking integrado y simple
Con jest.fn() o jest.mock() aísla servicios y APIs globales sin configurar librerías adicionales.
Snapshot testing
Captura la salida del componente y detecta al momento cualquier cambio inesperado en la UI.

En conjunto, obtienes ciclos de feedback mucho más rápidos, builds de CI más baratas y una confianza mayor en cada refactor.

Conclusión

Dar el salto de Karma/Jasmine a Jest es pasar de un motor con años de servicio a uno pensado para la velocidad y la claridad de hoy. En minutos tendrás:

Pruebas que se ejecutan en paralelo y terminan antes de que apures el café.
Cobertura de código con un simple --coverage, sin plugins ni rodeos.
Mocks y snapshots listos para blindar cada refactor.

Cada segundo ganado en el test runner vuelve a tu desarrollo: menos espera, más funciones nuevas, mayor confianza.

¿Quieres ver cómo aplicar Jest a casos reales y tener ejemplos de producción listos para copiar y pegar? Descúbrelo en nuestro eBook y lleva tus pruebas al siguiente nivel. Haz clic aquí y conviértete en el desarrollador que rompe la barra de progreso antes de que empiece a cargar.

Cómo Crear un Framework de JavaScript desde Cero - La Historia de Brisa Build

Bezael Pérez — Mon, 28 Oct 2024 22:50:00 +0000

En el mundo de desarrollo web, los frameworks de JavaScript se han vuelto herramientas esenciales para la creación de aplicaciones modernas. Desde Angular y React hasta Vue y Svelte, cada uno ofrece un enfoque único para resolver problemas de arquitectura, rendimiento y experiencia de usuario. Sin embargo, muchos desarrolladores se han preguntado: ¿realmente necesitamos otro framework de JavaScript?

Hoy quiero compartir la historia de cómo y por qué se creó Brisa, un nuevo framework de JavaScript, de la mano de su propio creador, Aral Roca. Brisa no solo busca resolver problemas específicos de performance y modularidad en aplicaciones web, sino que también plantea una visión innovadora sobre cómo los desarrolladores pueden construir interfaces modernas sin perder de vista el funcionamiento interno de la web y el servidor.

¿Qué es Brisa?

Brisa es un framework que ha sido desarrollado desde cero con el propósito de mejorar la comunicación entre el cliente y el servidor, aprovechando al máximo la tecnología de web components y signals. Uno de los principales problemas que Aral identificó en muchos frameworks actuales era la complejidad de manejar acciones del servidor y del cliente de forma eficiente. Con Brisa, cualquier evento puede ejecutarse en el servidor, y el código que se necesita en el cliente es mínimo.

Un aspecto innovador de Brisa es que funciona sin necesidad de escribir código en el cliente para manejar eventos en el servidor. A través de un sistema llamado RPC (Remote Procedure Call) de solo 2 KB, Brisa permite que las interacciones se procesen directamente desde el servidor. Esto no solo facilita el desarrollo, sino que también reduce significativamente la cantidad de código necesario en el cliente, mejorando así el rendimiento general de la aplicación.

El Origen de Brisa

La idea de crear Brisa nació cuando Aral tuvo una conversación inspiradora con Misko Hevery, el creador de Quick.js, durante un evento en Barcelona. La visión de Misko y su enfoque para mejorar la performance en aplicaciones web dejaron una marca en Aral.
"Fue como si estuviera hablando de su propio hijo", dice Aral, recordando la conversación. Inspirado por este nivel de pasión y compromiso, Aral decidió que él también quería crear un framework, pero no uno más en el montón; quería algo que resolviera problemas que él mismo había enfrentado.

Así, comenzó a trabajar en Brisa, un proyecto que combina lo mejor de las interacciones en tiempo real entre cliente y servidor, y que es lo suficientemente ligero como para integrarse sin fricciones con otros componentes web. Brisa surgió como un experimento que luego se convirtió en un framework completo, diseñado para la eficiencia y la escalabilidad en la web moderna.

Principales Características de Brisa

Server Actions sin Us Client y Us Server: En Brisa, todo el código se ejecuta en el servidor por defecto. Solo en situaciones específicas se habilita la ejecución en el cliente, lo cual simplifica la gestión del código y evita complejidades innecesarias.

Components Web Integrados: Los web components de Brisa son completamente modulares y se pueden utilizar en otros frameworks. Esto significa que cualquier componente creado en Brisa se puede reutilizar en React, Angular, o Vue, brindando a los desarrolladores mayor flexibilidad.

Signals Avanzados: Brisa implementa un sistema de signals para la gestión de estados. Estos signals permiten que los componentes se actualicen automáticamente cuando cambian sus propiedades, sin necesidad de un render completo de la página. Esto optimiza el rendimiento y reduce la carga del cliente.

RPC de Solo 2 KB: Uno de los aspectos más innovadores de Brisa es su sistema de RPC de solo 2 KB, que permite a los desarrolladores manejar interacciones desde el servidor sin necesidad de escribir código en el cliente. Esto resulta en un código mucho más ligero y simplificado, mejorando la eficiencia general de las aplicaciones.

¿Realmente Necesitamos Otro Framework?

Es comprensible que algunos desarrolladores se pregunten si realmente necesitamos otro framework de JavaScript. La respuesta de Aral Roca es clara: "Con cada nuevo framework vienen nuevas oportunidades de mejorar y de aprender".

A lo largo de los años, hemos visto cómo cada framework ha aportado algo diferente y único. React nos enseñó sobre el virtual DOM, Angular sobre la modularidad en gran escala, y Vue sobre la simplicidad en el desarrollo de componentes. Brisa, por su parte, nos muestra cómo combinar la potencia de la plataforma web y las técnicas de renderizado desde el servidor para optimizar aplicaciones modernas.

Aplicaciones de Brisa en el Mundo Real

Las ventajas de Brisa son particularmente valiosas en aplicaciones de alto rendimiento, como aquellas que requieren de cargas rápidas y mínima latencia en el manejo de datos en tiempo real. Brisa permite que la comunicación entre el cliente y el servidor sea mucho más eficiente, lo cual resulta ideal para aplicaciones que manejan un gran volumen de interacciones de usuario.
Además, su integración con los web components facilita la creación de aplicaciones modulares que pueden integrarse con otras tecnologías sin problemas.

La Comunidad Detrás de Brisa

Aral también enfatiza la importancia de la comunidad en el desarrollo de Brisa. Para él, el apoyo y las contribuciones de otros desarrolladores han sido fundamentales. “La mejor parte de trabajar en Brisa ha sido la oportunidad de aprender de otros desarrolladores y ver cómo ellos aplican este framework en sus propios proyectos”, comenta Aral. Brisa es un framework abierto y siempre se anima a la comunidad a contribuir, ya sea con ideas, reporte de problemas, o nuevas funcionalidades.

¿Qué Sigue para Brisa?

Aral tiene grandes planes para el futuro de Brisa. Con la posibilidad de que los signals sean incluidos en la web platform oficial gracias a TC39, el comité encargado de la evolución de JavaScript, Brisa está en una excelente posición para volverse aún más eficiente y ligero. Si se incluye la funcionalidad de signals en el lenguaje base, las aplicaciones que usen Brisa podrían beneficiarse de un rendimiento aún mayor, con menos dependencia de bibliotecas externas.

¿Quieres Probar Brisa?

Si eres un desarrollador curioso o te interesa conocer más sobre la arquitectura de aplicaciones web avanzadas, te invito a darle una oportunidad a Brisa. No solo verás un enfoque innovador para resolver problemas de rendimiento y modularidad, sino que también podrás aprender sobre las últimas tendencias en el desarrollo de JavaScript.

¡Comparte tus pensamientos en los comentarios!
¿Te entusiasma la idea de un nuevo framework como Brisa?
¿Qué piensas sobre el futuro de los frameworks de JavaScript?

¡Espero tus opiniones!

Microfrontends con Module Federation

Bezael Pérez — Sun, 09 Apr 2023 12:37:02 +0000

En los últimos años, las aplicaciones web han evolucionado hacia arquitecturas más complejas y modulares, lo que ha llevado a la aparición de nuevos conceptos y tecnologías que facilitan el desarrollo y mantenimiento de dichas aplicaciones. En este contexto, surge el concepto de microfrontends y la técnica conocida como Module Federation.

A continuación, se presenta el concepto de microfrontends, se describe brevemente Module Federation y se establece la importancia de combinar ambos enfoques para mejorar la calidad y escalabilidad de las aplicaciones web modernas.

Los microfrontends son un enfoque arquitectónico que busca dividir una aplicación web en partes más pequeñas e independientes, llamadas micro-app, permitiendo que cada parte sea desarrollada, probada y desplegada de forma autónoma.

Esta técnica se inspira en la arquitectura de microservicios, ampliamente utilizada en el desarrollo de aplicaciones backend, y busca replicar sus ventajas en el ámbito del frontend.

Ambos conceptos, microfrontends y microservicios, están estrechamente relacionados ya que buscan abordar problemas similares en sus respectivas capas de aplicación: mejorar la escalabilidad, la mantenibilidad y la flexibilidad.

Algunos de los beneficios de utilizar microfrontends incluyen la mejora en la escalabilidad, la facilidad de mantenimiento y la posibilidad de emplear diferentes tecnologías en cada micro-app del frontend.

Module Federation

Module Federation es una característica introducida en Webpack 5 que permite a múltiples aplicaciones JavaScript compartir dependencias y módulos de código en tiempo de ejecución.

Esto significa que las aplicaciones pueden cargar módulos de otras aplicaciones de forma dinámica, sin la necesidad de incluirlos en su propio código fuente.

Esta técnica permite que diferentes equipos de desarrollo colaboren de manera más eficiente y ahorren recursos al evitar la duplicación de código en aplicaciones separadas.

La combinación de microfrontends con Module Federation ofrece una serie de ventajas significativas para el desarrollo de aplicaciones web modernas.

Al utilizar microfrontends, se facilita la distribución del trabajo entre diferentes equipos, permitiendo que cada uno se enfoque en su respectiva parte de la aplicación.

Además, el uso de Module Federation permite compartir y reutilizar módulos de código entre los distintos microfrontends, lo que optimiza el rendimiento y reduce la duplicidad de código.

Beneficios Microfrontend

Escalabilidad: Dividir la aplicación de front-end en componentes más pequeños permite a los equipos trabajar de manera más eficiente y escalar sus esfuerzos de desarrollo. Esto también permite a las organizaciones asignar recursos de manera más eficiente a diferentes partes de la aplicación, en función de las necesidades y prioridades del negocio.

Mantenibilidad: Los componentes de un microfrontend son más fáciles de mantener, ya que cada uno es autónomo y tiene su propio conjunto de responsabilidades. Esto facilita la actualización, la corrección de errores y la mejora de cada componente sin afectar a otros componentes o al sistema en general.

Desacoplamiento: Los microfrontends promueven un enfoque de desarrollo desacoplado, en el que cada componente puede evolucionar de forma independiente y a su propio ritmo. Esto permite a los equipos de desarrollo adoptar diferentes tecnologías y prácticas sin afectar a otros equipos o componentes.

Facilita la colaboración entre equipos: Al dividir el front-end en componentes más pequeños, diferentes equipos pueden trabajar de forma independiente en diferentes partes de la aplicación. Esto reduce la necesidad de coordinación y comunicación entre equipos, lo que puede agilizar el proceso de desarrollo y mejorar la productividad.

Reutilización de componentes: Los microfrontends permiten la creación de componentes reutilizables que pueden ser compartidos entre diferentes partes de la aplicación o incluso entre diferentes aplicaciones. Esto puede reducir la duplicación de esfuerzos y mejorar la coherencia en la experiencia del usuario.

Mejora la resiliencia: Al aislar los componentes y evitar la interdependencia entre ellos, los microfrontends pueden mejorar la resiliencia de la aplicación. Si un componente falla, es menos probable que afecte a otros componentes o a la aplicación en su conjunto.

Antes de pasar a la implementación técnica, debemos comprender algunos conceptos básicos para entender como funciona module federation.

Module federation permite que una aplicación JavaScript ejecute código de forma dinámica desde otro paquete (aplicación) o se construya tanto en el cliente como en el servidor.

Module federation proporciona dos conceptos clave que debemos comprender antes de trabajar con ellas.

Host: El contenedor encargado de cargar, micro-frontends o componentes en tiempo de ejecución desde otras aplicaciones.

El host, también puede ser conocido, como container o shell

Remote: El bundle de javascript que queremos cargar dentro de un host.

Tu primer Microfrontend

Voy a utilizar un package de npm llamado create-mf-app, realmente podríamos hacerlo manualmente.

De hecho si ya tienes tus aplicaciones creadas solo debes añadir el fichero webpack.config.js en cada una de tu aplicación.

Ejecuta este comando



npx i create-mf-app

A partir de ahora en la terminal, verás varias opciones.

La primera es el nombre de nuestra aplicación, yo le he llamado container



? Pick the name of your app: (host)

El tipo de nuestra aplicación, aquí tenemos tres opciones. Application, API Server y LIbrary.

Vamos a escoger la primera opción*.* Application



? Project Type: (Use arrow keys)
> Application
  API Server
  Library

Ahora es el turno del puerto, vamos a elegir el puerto 4000



? Port number: (8080)

Para este ejemplo, yo voy a utilizar dos aplicaciones de React, anque recuerda que puedes usar varios frameworks.



? Framework: (Use arrow keys)
  lit-html
  mithril
  preact
> react
  solid-js
  svelte
  vanilla

Yo, voy a escoger TypeScript type safe 👨‍💻💪



? Language:
> typescript
  javascript

Los estilos para esta demo no tienen importancia, pero yo escogí Tailwind



`? CSS: (Use arrow keys)
  CSS
> Tailwind
```

Y finalmente ya tendremos nuestra aplicación, los siguentes pasos serán acceder a la carperta y ejecutar `npm install && npm start`

```bash
Your 'host' project is ready to go.

Next steps:

▶️ cd container
▶️ npm install
▶️ npm start
```

Bien, para la creación de la segunda aplicación los pasos serán los mismos, pero con otro nombre obviamente. En mi caso le he llamado ***remote.***  
En tu editor de codigo favorito, abre el proyecto.

Y nos centraremos en el ***webpack.config.js***, y principalmente en el apartado de plugins, en el *plugin* **ModuleFederationPlugin**.  
Podremos ver varias propiedades que utiliza webpack, para configurar el comportamiento de nuestra aplicación.

```javascript
  plugins: [
    new ModuleFederationPlugin({
      name: "container",
      filename: "remoteEntry.js",
      remotes: {},
      exposes: {},
      shared: {
        ...deps,
        react: {
          singleton: true,
          requiredVersion: deps.react,
        },
        "react-dom": {
          singleton: true,
          requiredVersion: deps["react-dom"],
        },
      },
    }),
    new HtmlWebPackPlugin({
      template: "./src/index.html",
    }),
  ],
```

**ModuleFederationPlugin**, es un plugin de webpack que permite compartir módulos entre diferentes aplicaciones y proyectos en tiempo de ejecución, sin tener que empaquetarlos en cada proyecto.

El plugin facilita la integración de varias aplicaciones en una sola página, lo que mejora el rendimiento y la experiencia del usuario.

En la configuración del plugin, se establece el nombre de la aplicación actual como container, *(name)* el nombre del archivo de entrada remota como ***remoteEntry.js***, y se definen las propiedades ***remotes***, ***exposes*** y ***shared***.

La propiedad ***remotes*** se utiliza para especificar los módulos que se importarán de forma remota. En este caso, se establece como un objeto vacío, lo que significa que no hay módulos remotos.

La propiedad ***exposes*** se utiliza para definir los módulos que se exponen a otros proyectos. En este caso, se establece como un objeto vacío, lo que significa que no se están exponiendo módulos.  

Vamos a crear un componente de React en nuestra aplicación ***remote***

```typescript
// Header.tsx
import React, { FC } from 'react';

interface HeaderProps {}

const Header: FC<HeaderProps> = () => {
  return <div className='p-5 bg-blue-600 text-white text-3xl'>Header V1</div>;
};

export default Header;
```

Ahora lo voy añadir a mi ***App.tsx*** (aunque realmente esto no es importante para el ejemplo)  
Ahora nuestra aplicación remote debe lucir algo como esto.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1680882324209/64f93a21-735b-439b-bf45-fa6144d72c8e.png align="center")

Great 🙂

Ahora que tenemos nuestro componente Header lo vamos a exponer.  
Volvamos al fichero ***webpack.config.js*** y en la propiedad ***exposes*** añadimos lo siguiente.  

```javascript
      exposes: {
        './Header': './src/Header.tsx',
      }
```

Con esto estamos exponiendo nuestro header para que pueda ser consumido por otras aplicaciones.

Para comprobar que se está sirviendo de la manera correcta, podemos acceder a la siguiente url [*http://localhost:4001/remoteEntry.js*](http://localhost:4001/remoteEntry.js)  
**Asegurate de reiniciar el la aplicación**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1680893338479/cc17ed48-cf66-4415-ade4-98cc0f1e4bc5.png align="center")

Lo siguiente, que haremos es consumir el *Header* expuesto por el *remote.*

Volvamos al fichero ***webpack.config.js*** y en la propiedad ***remotes*** pero del **container.**

```javascript
  plugins: [
    new ModuleFederationPlugin({
      name: "container",
      filename: "remoteEntry.js",
      remotes: {
        'components': 'remote@http://localhost:4001/remoteEntry.js',
      },
      exposes: {},
      shared: {
        ...deps,
        react: {
          singleton: true,
          requiredVersion: deps.react,
        },
        "react-dom": {
          singleton: true,
          requiredVersion: deps["react-dom"],
        },
      },
    }),
    new HtmlWebPackPlugin({
      template: "./src/index.html",
    }),
  ],
```

Ahora estamos listos para utilizar nuestro componentes remote.

```typescript
// App.tsx  
import React from 'react';
import ReactDOM from 'react-dom';

import './index.scss';
import Header from 'components/Header';

const App = () => (
  <>
    <Header />
    <div className='max-w-6xl mx-auto mt-10 text-3xl'>
      <div>Name: container</div>
      <div>Framework: react</div>
      <div>Language: TypeScript</div>
      <div>CSS: Tailwind</div>
    </div>
  </>
);
ReactDOM.render(<App />, document.getElementById('app'));
```

Modificamos la aplicación container, el componente ***App.tsx***

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1680973639230/acf14603-1e78-4b78-87e9-1a9d5c32bf57.png align="center")

Deberías ver algo como esto en tu aplicación container.

Esto solo es un pequeña muestra de lo que podríamos lograr con Webpack 5 y *Module federation.*

[Aquí tienes el reposito de la demo](https://github.com/domini-code/module-federation-react)

Mejorar el rendimiento de *ngFor con trackBy

Bezael Pérez — Sat, 16 May 2020 11:51:52 +0000

En un principio mi intención era hablar sobre la directiva ngFor*, mientras me documentaba y revisaba apuntes, recordé trackBy.

¿Por qué nos olvidamos de trackBy?

La verdad que no lo sé, pero todo lo que pueda ayudar mejorar el perfomance de mi aplicación es bienvenido.

En este post vamos a hablar sobe trackBy, como nos puede ayudar a mejorar el rendimiento.

*ngFor

La directiva ngFor es comúnmente usada para iterar sobre un array.
ngFor exporta algunas variables locales que podemos utilizar durante la iteración actual:

index: iteración de bucle actual para cada contexto del template.
first: valor booleano que indica si el elemento es el primero en la iteración.
last: valor booleano que indica si el elemento es el último en la iteración.
even: valor que indica si este elemento tiene un índice par.
odd: valor booleano que indica si este elemento tiene un índice impar.

En este ejemplo la directiva recorrería todo el array de items.
Y se renderiza el contenido de item.

Angular convertirá este código en lo siguiente.

Hasta aquí todo bien, ningún problema a la vista.

Pero internamente cada vez se añada, modifiques o elimines un item del array, Angular a través de la directiva *ngFor volverá a redibujar completemente el DOM desde cero. Y esto es una operación costosa.

En aplicaciones medianas o grandes esto puede llegar a ser un problema.

Debería existir algo capaz de encargarse de realizar un seguimiento de los cambios en el array por lo tanto en el los elementos y que solo hiciera los cambios o el cambio en los items necesarios.

Y sí, existe y es trackBy.

Vamos a mejorar nuestro ejemplo anterior.

En nuestro .ts

trackBy

Es una función que define cómo realizar un seguimiento de los cambios para los elementos en el iterable.

Ahora cada vez que se agregue, mueva o elimine elementos en el array,

Cuando se agregan, mueven o eliminan elementos en el iterable, la directiva, sólo volverá a redibujar los items que han cambiado.

Cuando se proporciona esta función, la directiva utiliza el resultado de llamar a esta función para identificar el nodo del elemento, en lugar de la identidad del objeto en sí.

La función recibe dos entradas, el índice de iteración y el ID del objeto del nodo (item).

Pues esto es todo por este post!
Si te ha gustado recuerdo compartirlo.

Hasta la próxima

Formularios reactivos en Angular 8

Bezael Pérez — Mon, 27 Jan 2020 18:57:33 +0000

Los formularios son parte esencial de nuestras aplicaciones.
En Angular tenemos dos enfoques de formularios, Template forms y Reactive Forms.

Desde un login, un formulario para reservar un hotel, o formularios para realizar trámites gubernamentales. Cualquiera de estos formularios lo podríamos hacer con Reactive Forms.

Aunque en una primera instancia para formularios más sencillos podríamos usar template forms.

Y para casos más avanzados podemos usar reactive forms.

Pero esto es solo son supuestos.

Los formularios reactivos utilizan un enfoque explícito e inmutable.
Los datos de dichos formularios están enlazados con nuestro objeto de manera sincrónica.

Ya sabemos que tenemos dos opciones para trabajar con formularios en Angular; En esta ocasión me voy a centrar en los formularios reactivos.

Los formularios reactivos son más robustos (escalables) que los
formularios template driven.

Si tu aplicación está basada en formularios, te recomiendo que utilizes formularios reactivos.

Bueno, basta de hablarte de las bondades de los formularios reactivos y vamos a ver un ejemplo.

Vamos a crear un formulario de contacto básico. Y guardaremos cada consulta en Firebase Cloud Firestore.

Y por supuesto tendremos validaciones en nuestro formulario.
Empecemos creando un nuevo proyecto de Angular.

Yo voy a utilizar Angular 8, pero este ejemplo es compatible prácticamente al 100% en otras versiones.

ng new reactiveForms

Para este ejemplo no necesitamos rutas.
Would you like to add Angular routing? (y/N)

Para los estilos escogemos SCSS

Asegurate de estar dentro de la carpeta del proyecto y vamos a crear un componente.

Creamos un componente para pintar nuestro formulario.

ng g c components/contact

Vamos al componente principal app.component.html
Sustituye todo lo que hay ahora por lo siguiente.

Luego de este cambio podemos arrancar nuestro server.
ng serve

Ahora podemos acceder a la url http://localhost:4200/

Nada fancy hasta ahora, pero ya estamos listos para trabajar con nuestro formulario.

Ahora que tenemos nuestra app y el componente creado.

Vamos a crearnos una aplicación en la consola de Firebase.

Es necesario que tengas una cuenta ya creada de Firebase

Primero vamos a https://console.firebase.google.com

Verás algo como esto, es posible que tú lo veas distinto si no tienes ningún proyecto creado, como puedes ver yo tengo algunos proyectos.

Haz clic en AÑADIR PROYECTO
Elige un nombre para tu proyecto -> aceptas las condiciones y Hacemos clic en CREAR PROYECTO

Luego de varias preguntas llegarás al proyecto.
Podrás ver algo como esto.

En Firebase podemos trabajar con aplicaciones móviles Android e ios y por supuesto web.
Vamos a hacer clic en icono de aplicaciones web (el tercero del recuadro).

Elige una nombre para registrar tu app.

Finalmente ya tenemos nuestra app creada, lo que se puede ver en el pantallazo anterior, es la información que utilizaremos para conectarnos a Firebase.

La parte importante para nosotros es el contenido de la variable firebaseConfig

Asegurate de crear tu propia app.

Debemos crear una base de datos.

En el menú de las izquierda selecciona Database y luego haz clic en Crear base de datos.

Elige: Empezar con el modo de prueba Y por último haremos clic en Listo.
Una vez que ya tenemos los datos de configuración para conectarnos a firebase.

Vamos a nuestro proyecto y en el fichero environment.ts

Vamos a realizar la instalación de las dependencia de firebase y @angular/fire

Desde nuestra consola ejecutamos el siguiente comando.
Vamos a aprovechar las ventajas de los Schematics.

ng add @angular/fire

OJO, el proyecto debes estar creado en firebase console

Con este comando instalamos varios packages.

Nota: Este tutorial está realizado en la versión 5.5.7 de firebase y 5.3.0 de @angular/fire

Ahora vamos al fichero app.module para realizar unas importaciones.

Importamos dos módulos de @angular/fire, el fichero de environment y el module que nos va permitir trabajar con formularios reactivos.

En el apartado de imports inyectamos el módulo de formularios reactivos, el Firestore Module e inicializamos el AngularFire Module pasandole nuestro fichero de configuración.

Este sería el resultado final.

Necesitamos crear un service, para crear los métodos que vamos a utilizar para guardar las consultas de nuestro formulario.

Desde la consola ejecutamos el comando
ng g s services/data

Ahora abrimos el fichero data.service.ts
Y realizamos las siguientes importaciones.

A continuación declaramos una propiedad
contactCollection

En el método constructor le asignamos nuestra colección contacts, que será donde guardaremos la información.

Creamos el método saveMessage, para guardar en nuestra colección.

Este sería el resultado final del data.service.ts

En el componente

En el componente contact.component.ts
Este sería el resultado final del fichero, a continuación paso a comentar los más destacado.

En la línea 2 & 3 hago las importaciones del DataService y también necesitamos importar FormControl, FormGroup & Validators para trabajar con el módulo de formulario reactivo.

Creamos una propiedad llamada contactForm de tipo FormGroup.
La propiedad emailPattern, es tan solo una Regex para validar si el usuario ha introducido una email válido.

Luego, lo más destacable puede el método createForm donde creamos la instancia del formulario y asignamos la validaciones pertinentes.
Las propias validaciones en sí, son muy descriptivas.

Todos nuestros campos serán requeridos y con el método minLength(), indicamos el número mínimo para este campo.

También tenemos un método para hacer el reset de nuestro formulario, y onSaveForm para llamar el método saveMessage y le pasamos todo nuestro formulario.

Procedemos a trabajar con el HTML.
En el fichero contact.component.html
Vamos a tener el html. Aquí no hay mucho que explicar.

Los más reseñable es la linea 3

Donde enlazamos nuestra instancia con el formulario.

Y cuando ocurre el evento onSubmit llamamos al método onSaveForm.
Si arrancas la aplicación verás que no luce muy bien.

Vamos a añadir estilos. Este será el resultado final y recuerda que tienes el repo, donde puedes copiar estos estilos.

Arranca el server y vamos a probar nuestra app.
Como puedes ver el resultado es un formulario básico, que guarda las consultas en Firebase.

Tienes la demo aquí

Si quieres ver el video en Youtube, te dejo el link por aquí, también tienes el código aquí.

Un saludo y no olvides compartir. Gracias!!!

DEV Community: Bezael Pérez

Spec-Driven Development: el método para construir con IA sin perder el control

El vibe coding tiene un límite

Qué es SDD

Lo que SDD no es

Las 7 fases del flujo

Fase 1: Idea

Fase 2: Research (opcional)

Fase 3: Prototipo (opcional)

Fase 4: PRD (La spec)

Fase 5: Kanban

Fase 6: Execution loop

Fase 7: QA

El flujo en una imagen

Por qué ahora

Para empezar hoy

Tu app de vibe coding funciona. Eso es exactamente el problema.

Lo que la IA no te dice cuando genera tu código

/vibe-audit — 30 segundos para saber en qué lío estás

Los problemas que encuentra. Siempre.

El resto del kit

La diferencia entre vibe coding y vibe coding bien hecho

Your vibe coding app works. That's exactly the problem.

What the AI doesn't tell you when it generates your code

/vibe-audit — 30 seconds to know what mess you're in

The problems it finds. Every time.

The rest of the kit

The difference between vibe coding and vibe coding done right

De Senior Dev a Tech Lead: la transición donde más talento se pierde ¿Te ha pasado?

Por qué los desarrolladores que pasan a tech lead fracasan…

Por qué los desarrolladores que pasan a tech lead fracasan…

De Senior Dev a Tech Lead: la transición donde más talento se pierde

El conflicto central

🚨 Los 5 errores más comunes (y cómo evitarlos)

1. El síndrome del héroe

2. El micromanagement disfrazado de “calidad”

3. Falla de comunicación

4. Olvidar el factor humano

5. Seguir queriendo ser el mejor programador

💡 En resumen

Jest 30: Más Rápido, Inteligente y Listo para el Futuro. ¿Es Hora de Actualizar?

¿Por qué esta actualización es un punto de inflexión?

Adiós a la Lentitud

Nuevas Herramientas para el Desarrollador

La Migración: ¿Vale la Pena el Esfuerzo?

El Futuro de las Pruebas y Cómo Dominarlo

Conclusión: Un Nuevo Comienzo para Jest

De Jasmine a Jest: Migración sin dolor en 30 minutos

La verdad incómoda sobre Karma

Por qué Jest está ganando terreno en silencio

Tu plan exprés de 30 minutos

Lo que nadie te cuenta (pero necesitas saber)

¿Qué pasa si lo dejas para mañana?

Da el salto ahora mismo

Recuerda el beneficio final

Paso 1 – Instala lo esencial sin perder un minuto

2. Ajuste del package.json

3. Configuración de tsconfig.spec.json

4. Creación de jest.config.ts

5. Creación de setup-jest.ts

Por qué importa

Lo que debe ocurrir dentro

6. Deja atrás el lastre de Karma y Jasmine

Ejemplo mínimo: Conversión de una prueba tradicional a Jest con Testing Library

Por qué tus ajustes son oro puro

Cómo exprimir aún más tu nueva base

Bonus: Jest y Angular Testing Library

¿Prefieres aprender mirando? Aquí tienes tu atajo visual

Beneficios medibles: Tiempo de ejecución y reporte de cobertura

Conclusión

Cómo Crear un Framework de JavaScript desde Cero - La Historia de Brisa Build

¿Qué es Brisa?

El Origen de Brisa

Principales Características de Brisa

¿Realmente Necesitamos Otro Framework?

Aplicaciones de Brisa en el Mundo Real

La Comunidad Detrás de Brisa

¿Qué Sigue para Brisa?

¿Quieres Probar Brisa?

Microfrontends con Module Federation

`/vibe-audit` — 30 segundos para saber en qué lío estás

`/vibe-audit` — 30 seconds to know what mess you're in

2. Ajuste del `package.json`

3. Configuración de `tsconfig.spec.json`

4. Creación de `jest.config.ts`

5. Creación de `setup-jest.ts`