Pruebas unitarias con Mocha y Chai

Posted on by marta

En desarrollo de software, escribir código que funcione es importante. Pero escribir código que podamos mantener, refactorizar y comprobar con confianza es todavía más importante. Ahí es donde entran en juego las pruebas unitarias, una práctica esencial para reducir errores, detectar regresiones y construir aplicaciones más sólidas.

Cuando trabajamos con JavaScript, existen muchas herramientas para crear tests: Jest, Vitest, Jasmine, el propio runner de Node.js y, por supuesto, la combinación formada por Mocha y Chai. Aunque han aparecido alternativas más recientes, Mocha y Chai siguen siendo una opción muy interesante por su flexibilidad, su claridad y su capacidad para adaptarse a distintos tipos de proyectos.

Mocha se encarga de organizar y ejecutar los tests. Chai, por su parte, nos ayuda a escribir las afirmaciones que comprueban si el resultado obtenido coincide con el resultado esperado. Dicho de forma sencilla: Mocha estructura la prueba y Chai expresa la expectativa.

Si ya has trabajado con JavaScript y quieres empezar a mejorar la calidad de tu código, este artículo te ayudará a entender cómo funcionan las pruebas unitarias con Mocha y Chai, cómo instalarlas, cómo escribir tus primeros tests y qué buenas prácticas conviene seguir para que las pruebas sean realmente útiles dentro de un proyecto.

Además, si te interesa seguir profundizando en testing, también puedes complementar esta lectura con el artículo sobre uso práctico de Mocha y Chai para pruebas en JavaScript, donde se trabajan ejemplos más concretos paso a paso.

Qué son las pruebas unitarias y por qué son importantes

Las pruebas unitarias son tests que verifican el comportamiento de una unidad pequeña de código de forma aislada. Esa unidad puede ser una función, un método, una clase, un helper o una pequeña pieza de lógica de negocio.

La idea principal es comprobar que una parte concreta del sistema hace exactamente lo que esperamos. Por ejemplo, si tenemos una función que calcula el precio final de un producto con IVA, una prueba unitaria debería validar que, al pasarle un precio base y un porcentaje de impuesto, el resultado sea correcto.

function calcularPrecioConIVA(precio, iva) {
  return precio + precio * iva;
}

Una prueba unitaria para esa función podría comprobar que, si el precio es 100 y el IVA es 0.21, el resultado sea 121.

La utilidad de este tipo de pruebas no está solo en encontrar errores. Su verdadero valor aparece cuando el proyecto crece. Si modificamos una función, cambiamos una dependencia o reorganizamos parte del código, los tests nos ayudan a comprobar rápidamente si algo que antes funcionaba ha dejado de hacerlo.

En otras palabras, las pruebas unitarias actúan como una red de seguridad. No eliminan todos los errores, pero sí reducen mucho el riesgo de romper funcionalidades existentes sin darnos cuenta.

Ventajas de aplicar pruebas unitarias

Implementar pruebas unitarias con Mocha y Chai puede aportar beneficios muy claros:

  • Permiten detectar errores de forma temprana.
  • Facilitan la refactorización del código.
  • Ayudan a documentar el comportamiento esperado de una función.
  • Mejoran la confianza al hacer cambios.
  • Reducen el coste de mantenimiento a largo plazo.
  • Favorecen una arquitectura más modular y desacoplada.

Además, escribir tests obliga a pensar mejor la estructura del código. Si una función es muy difícil de probar, normalmente es una señal de que hace demasiadas cosas o depende demasiado de elementos externos.

Esto conecta directamente con una idea clave del desarrollo frontend moderno: cuanto más clara es la responsabilidad de cada pieza, más fácil resulta mantenerla, probarla y escalarla. Lo mismo ocurre cuando trabajamos con componentes, estados o utilidades en proyectos con frameworks como React, algo que también puedes ver en contenidos relacionados como pruebas en React y React Testing Library.

Qué es Mocha

Mocha es un framework de testing para JavaScript que permite definir, organizar y ejecutar pruebas. Se puede utilizar en proyectos Node.js y también en entornos de navegador.

Una de sus principales ventajas es que no impone una única forma de trabajar. Mocha proporciona la estructura de ejecución, pero nos deja elegir otras herramientas para las aserciones, los mocks, los stubs o la cobertura de código.

Por eso se suele decir que Mocha es una herramienta flexible. No viene con todas las decisiones tomadas de antemano, lo que puede ser una ventaja en proyectos donde necesitamos adaptar el entorno de testing a nuestras necesidades.

Cómo organiza Mocha los tests

Mocha utiliza una sintaxis muy legible basada en bloques como describe() e it().

describe("calcularPrecioConIVA", function () {
  it("debería calcular el precio final con IVA", function () {
    // prueba aquí
  });
});

El bloque describe() sirve para agrupar pruebas relacionadas. Normalmente se utiliza para indicar qué función, módulo o comportamiento estamos probando.

El bloque it() describe un caso concreto. Lo ideal es que su texto explique claramente qué debería ocurrir.

it("debería devolver 121 cuando el precio es 100 y el IVA es 21%", function () {
  // prueba aquí
});

Esta forma de escribir tests tiene una ventaja importante: el propio test se convierte en una pequeña documentación del comportamiento esperado del código.

Cuando alguien del equipo lee el test, puede entender qué hace esa función sin tener que revisar toda la implementación interna. Y cuando ese test falla, el mensaje describe con bastante precisión qué comportamiento ha dejado de cumplirse.

Hooks en Mocha

Mocha también permite utilizar hooks para preparar o limpiar el entorno antes y después de los tests. Los más habituales son:

before(function () {
  // Se ejecuta una vez antes de todos los tests
});

after(function () {
  // Se ejecuta una vez después de todos los tests
});

beforeEach(function () {
  // Se ejecuta antes de cada test
});

afterEach(function () {
  // Se ejecuta después de cada test
});

Estos hooks son útiles cuando necesitamos inicializar datos, crear una instancia, limpiar variables o preparar un estado común para varios tests.

Aun así, conviene usarlos con cuidado. Si abusamos de ellos, los tests pueden volverse difíciles de leer porque parte de la lógica queda escondida fuera del caso de prueba. Como norma general, un test debería poder entenderse sin tener que saltar constantemente entre varias partes del archivo.

Qué es Chai

Chai es una librería de aserciones para JavaScript. Su función es ayudarnos a expresar de forma clara qué esperamos que ocurra en una prueba.

Mientras Mocha ejecuta y organiza los tests, Chai permite escribir afirmaciones como esta:

expect(resultado).to.equal(121);

Esta línea significa: “espero que el resultado sea igual a 121”.

Chai puede utilizarse con diferentes estilos de aserción. Los más conocidos son:

  • expect
  • should
  • assert

En muchos proyectos modernos se utiliza expect porque resulta muy expresivo y fácil de leer.

Ejemplo con expect

import { expect } from "chai";

expect(2 + 2).to.equal(4);
expect("Mocha").to.be.a("string");
expect([1, 2, 3]).to.include(2);

La sintaxis de Chai está pensada para que las pruebas se puedan leer casi como frases. Esto ayuda a que el test sea más comprensible, incluso para personas que no escribieron originalmente ese código.

Chai y la legibilidad de las pruebas

Una buena prueba no solo debe funcionar. También debe ser fácil de entender.

Por eso Chai aporta mucho valor: permite escribir expectativas de forma más cercana al lenguaje natural. No es lo mismo leer esto:

assert.equal(resultado, 121);

que esto:

expect(resultado).to.equal(121);

Ambas opciones son válidas, pero expect suele resultar más expresiva cuando queremos construir tests claros y descriptivos.

La legibilidad no es un detalle menor. En proyectos reales, los tests también forman parte del código base. Por tanto, deben mantenerse con el mismo cuidado que el resto de archivos del proyecto.

Mocha y Chai juntos: una combinación sencilla y potente

Mocha y Chai se complementan muy bien porque cada herramienta se centra en una responsabilidad distinta.

Mocha responde a preguntas como:

  • ¿Dónde están los tests?
  • ¿Cómo se agrupan?
  • ¿Qué tests se ejecutan?
  • ¿Qué tests pasan y cuáles fallan?
  • ¿Cómo se muestran los resultados?

Chai responde a preguntas como:

  • ¿Qué valor esperaba?
  • ¿El resultado es igual al previsto?
  • ¿El array contiene determinado elemento?
  • ¿El objeto tiene cierta propiedad?
  • ¿La función lanza un error?

Esta separación hace que el entorno de pruebas sea más modular. Podemos usar Mocha con Chai, pero también podríamos combinar Mocha con otras librerías de aserciones. Del mismo modo, Chai puede integrarse con otros frameworks de testing.

Cuándo conviene usar Mocha y Chai

La combinación de Mocha y Chai es especialmente útil cuando queremos un entorno de testing claro, configurable y progresivo.

Puede ser una buena elección en estos casos:

  • Proyectos Node.js con lógica de negocio.
  • Librerías JavaScript reutilizables.
  • APIs donde queremos probar funciones, servicios o validadores.
  • Proyectos donde necesitamos una configuración flexible.
  • Equipos que prefieren separar framework de testing y librería de aserciones.

No siempre es necesario usar Mocha y Chai. En algunos proyectos modernos con Vite, por ejemplo, Vitest puede integrarse de forma muy cómoda. Pero Mocha y Chai siguen siendo una excelente opción cuando buscamos control, estabilidad y una sintaxis muy reconocible.

Esta decisión también depende del contexto técnico del proyecto. Si estás trabajando en una aplicación frontend moderna, puede interesarte revisar primero cómo está organizado tu stack, tus scripts de desarrollo y tus herramientas de automatización. En ese sentido, también puede resultarte útil el artículo sobre GitHub Actions, automatización e integración continua en desarrollo de software.

Cómo instalar Mocha y Chai en un proyecto JavaScript

Para empezar, necesitamos tener un proyecto Node.js inicializado. Si todavía no lo tenemos, podemos crearlo con:

npm init -y

Después instalamos Mocha y Chai como dependencias de desarrollo:

npm install --save-dev mocha chai

Una vez instaladas las dependencias, podemos crear una estructura básica como esta:

mi-proyecto/
├── src/
│   └── calculadora.js
├── test/
│   └── calculadora.test.js
├── package.json

En el archivo package.json, podemos añadir un script para ejecutar los tests:

{
  "scripts": {
    "test": "mocha"
  }
}

De esta forma, podremos lanzar las pruebas con:

npm test

Configuración con módulos ES

Si queremos utilizar import y export, podemos añadir "type": "module" en el package.json:

{
  "type": "module",
  "scripts": {
    "test": "mocha"
  },
  "devDependencies": {
    "chai": "^6.0.0",
    "mocha": "^11.0.0"
  }
}

Las versiones concretas pueden variar según el momento en que instales los paquetes, pero lo importante es entender la estructura general.

Si estás empezando también con tipado estático, te puede interesar complementar esta parte con una introducción a TypeScript y sus primeros pasos, ya que muchos proyectos actuales combinan tests con JavaScript moderno o TypeScript.

Primer ejemplo de prueba unitaria con Mocha y Chai

Imaginemos que tenemos una función sencilla para sumar dos números.

Archivo src/calculadora.js:

export function sumar(a, b) {
  return a + b;
}

Ahora creamos el archivo de prueba.

Archivo test/calculadora.test.js:

import { expect } from "chai";
import { sumar } from "../src/calculadora.js";

describe("sumar", function () {
  it("debería sumar dos números positivos", function () {
    const resultado = sumar(2, 3);

    expect(resultado).to.equal(5);
  });
});

Este test tiene tres partes claras:

  1. Importamos la función que queremos probar.
  2. Ejecutamos la función con unos valores concretos.
  3. Comprobamos que el resultado sea el esperado.

Si ejecutamos:

npm test

Mocha buscará los tests, los ejecutará y mostrará si han pasado o fallado.

Probando diferentes escenarios

Una sola prueba no siempre es suficiente. Para que una prueba unitaria sea útil, debemos pensar en distintos escenarios.

import { expect } from "chai";
import { sumar } from "../src/calculadora.js";

describe("sumar", function () {
  it("debería sumar dos números positivos", function () {
    expect(sumar(2, 3)).to.equal(5);
  });

  it("debería sumar números negativos", function () {
    expect(sumar(-2, -3)).to.equal(-5);
  });

  it("debería sumar un número positivo y uno negativo", function () {
    expect(sumar(10, -4)).to.equal(6);
  });

  it("debería devolver el mismo número al sumar cero", function () {
    expect(sumar(7, 0)).to.equal(7);
  });
});

Este ejemplo es muy simple, pero muestra una idea importante: no probamos solo el caso feliz. También conviene probar límites, casos especiales y combinaciones que podrían generar errores.

En desarrollo real, muchos bugs aparecen precisamente en los bordes: datos vacíos, valores inesperados, estados intermedios o entradas que no habíamos contemplado. Por eso, un buen conjunto de pruebas debe ir más allá del escenario ideal.

Ejemplo práctico: validar un carrito de compra

Veamos un caso un poco más cercano a un proyecto real. Imaginemos una función que calcula el total de un carrito.

Archivo src/carrito.js:

export function calcularTotal(productos) {
  return productos.reduce((total, producto) => {
    return total + producto.precio * producto.cantidad;
  }, 0);
}

Ahora escribimos los tests.

Archivo test/carrito.test.js:

import { expect } from "chai";
import { calcularTotal } from "../src/carrito.js";

describe("calcularTotal", function () {
  it("debería devolver 0 si el carrito está vacío", function () {
    const resultado = calcularTotal([]);

    expect(resultado).to.equal(0);
  });

  it("debería calcular el total de un producto", function () {
    const productos = [
      { nombre: "Curso JavaScript", precio: 30, cantidad: 1 }
    ];

    const resultado = calcularTotal(productos);

    expect(resultado).to.equal(30);
  });

  it("debería calcular el total de varios productos con distintas cantidades", function () {
    const productos = [
      { nombre: "Libro", precio: 20, cantidad: 2 },
      { nombre: "Plantilla", precio: 15, cantidad: 3 }
    ];

    const resultado = calcularTotal(productos);

    expect(resultado).to.equal(85);
  });
});

Este tipo de prueba resulta muy útil porque valida una regla de negocio concreta: cómo se calcula el total de un carrito.

Si más adelante modificamos la función para añadir descuentos, impuestos o gastos de envío, los tests nos ayudarán a saber si hemos roto el cálculo original.

Aquí se ve muy bien una de las grandes ventajas de las pruebas unitarias: nos permiten cambiar el código con más tranquilidad. No porque garanticen que todo sea perfecto, sino porque nos avisan cuando una pieza importante deja de comportarse como esperábamos.

Pruebas unitarias de errores y validaciones

En muchos casos, una función no solo debe devolver un resultado correcto. También debe gestionar errores o entradas inválidas.

Imaginemos una función que divide dos números:

export function dividir(a, b) {
  if (b === 0) {
    throw new Error("No se puede dividir entre cero");
  }

  return a / b;
}

Podemos probar tanto el caso correcto como el error:

import { expect } from "chai";
import { dividir } from "../src/dividir.js";

describe("dividir", function () {
  it("debería dividir dos números", function () {
    expect(dividir(10, 2)).to.equal(5);
  });

  it("debería lanzar un error si se divide entre cero", function () {
    expect(() => dividir(10, 0)).to.throw("No se puede dividir entre cero");
  });
});

Este tipo de prueba es importante porque valida el comportamiento completo de la función, no solo el resultado ideal.

Una aplicación robusta no es la que nunca recibe datos incorrectos, sino la que sabe responder bien cuando esos datos aparecen.

La importancia de probar entradas inválidas

En proyectos reales, no siempre recibimos datos limpios. Puede llegar un array vacío, un objeto incompleto, una cadena donde esperábamos un número o una respuesta externa con una estructura distinta a la prevista.

Por eso, cuando escribimos pruebas unitarias, conviene preguntarnos:

  • ¿Qué ocurre si falta un dato?
  • ¿Qué ocurre si el valor es null o undefined?
  • ¿Qué ocurre si el array está vacío?
  • ¿Qué ocurre si recibimos un tipo de dato inesperado?
  • ¿Qué error debería lanzarse en ese caso?

Estas preguntas ayudan a diseñar funciones más resistentes y fáciles de mantener.

Pruebas asíncronas con Mocha y Chai

JavaScript trabaja constantemente con código asíncrono: peticiones HTTP, lectura de archivos, consultas a bases de datos, temporizadores o promesas.

Mocha permite probar código asíncrono de varias formas. Una de las más cómodas es utilizando async y await.

Imaginemos esta función:

export async function obtenerUsuario(id) {
  if (!id) {
    throw new Error("El id es obligatorio");
  }

  return {
    id,
    nombre: "Marta"
  };
}

Podemos probarla así:

import { expect } from "chai";
import { obtenerUsuario } from "../src/usuario.js";

describe("obtenerUsuario", function () {
  it("debería devolver un usuario por id", async function () {
    const usuario = await obtenerUsuario(1);

    expect(usuario).to.deep.equal({
      id: 1,
      nombre: "Marta"
    });
  });
});

En este caso usamos deep.equal porque estamos comparando objetos. Si utilizáramos equal, Chai comprobaría si ambos objetos son exactamente la misma referencia en memoria, no si tienen el mismo contenido.

Cuidado con los tests asíncronos

Uno de los errores más habituales al probar código asíncrono es olvidar devolver la promesa o usar await.

Este test puede parecer correcto, pero no lo es:

it("debería devolver un usuario", function () {
  obtenerUsuario(1).then((usuario) => {
    expect(usuario.nombre).to.equal("Marta");
  });
});

El problema es que Mocha podría terminar el test antes de que la promesa se resuelva. Por eso, en la mayoría de casos, es preferible utilizar async/await:

it("debería devolver un usuario", async function () {
  const usuario = await obtenerUsuario(1);

  expect(usuario.nombre).to.equal("Marta");
});

La legibilidad mejora y el riesgo de falsos positivos se reduce.

Si además estás probando lógica relacionada con almacenamiento local, sesiones o persistencia en navegador, puedes complementar esta parte con el artículo sobre localStorage y sessionStorage en proyectos JavaScript, ya que muchas funciones de ese tipo también pueden beneficiarse de pruebas bien planteadas.

Buenas prácticas para escribir pruebas unitarias con Mocha y Chai

Escribir tests no consiste en llenar el proyecto de archivos .test.js. La calidad de una prueba depende de su claridad, su utilidad y su capacidad para detectar errores reales.

Escribe tests pequeños y específicos

Cada test debería comprobar una idea concreta. Si un test valida demasiadas cosas a la vez, será más difícil saber qué ha fallado cuando aparezca un error.

Un buen test debería poder responder con claridad a esta pregunta: ¿qué comportamiento exacto estoy verificando?

Por ejemplo, no es lo mismo comprobar “la función de carrito funciona” que comprobar “la función devuelve 0 cuando el carrito está vacío”. La segunda formulación es mucho más concreta y ayuda a detectar el origen del problema con mayor rapidez.

Usa nombres descriptivos

El texto dentro de it() debe explicar el comportamiento esperado.

Mejor esto:

it("debería devolver 0 cuando el carrito está vacío", function () {});

que esto:

it("test 1", function () {});

Los nombres descriptivos hacen que los resultados de Mocha sean mucho más útiles. Cuando una prueba falla, el propio nombre del test nos orienta sobre el problema.

Evita depender de otros tests

Una prueba unitaria debería poder ejecutarse de forma independiente. Si un test depende de que otro se haya ejecutado antes, el conjunto de pruebas se vuelve frágil.

Cada test debe preparar sus propios datos o utilizar hooks claros como beforeEach() cuando sea necesario.

La independencia de los tests es clave para evitar errores difíciles de rastrear. Si una prueba falla solo cuando se ejecuta después de otra, probablemente hay un problema de estado compartido.

Prueba casos límite

No te quedes solo con el caso más evidente. Algunas de las situaciones más valiosas para probar son:

  • Valores vacíos.
  • Valores nulos o indefinidos.
  • Números negativos.
  • Arrays vacíos.
  • Objetos incompletos.
  • Errores esperados.
  • Límites máximos y mínimos.

Los bugs suelen esconderse en los bordes, no en el camino perfecto.

No pruebes detalles de implementación

Una buena prueba se centra en el comportamiento, no en cómo está construido internamente el código.

Por ejemplo, si una función devuelve el resultado correcto, normalmente no debería importarnos si internamente usa map, reduce o un bucle for.

Probar demasiados detalles internos hace que los tests se rompan cada vez que refactorizamos, incluso aunque el comportamiento final siga siendo correcto.

La pregunta clave debería ser: ¿el código sigue haciendo lo que debe hacer? Si la respuesta es sí, el test no debería fallar solo porque hemos mejorado su implementación interna.

Errores comunes al empezar con Mocha y Chai

Aunque Mocha y Chai son herramientas bastante accesibles, es normal cometer algunos errores al principio.

Escribir tests demasiado genéricos

Un test como este aporta poco:

it("debería funcionar", function () {});

Conviene explicar qué significa “funcionar”. Los tests deben ser una guía, no un misterio.

Un buen test debería dejar claro qué entrada se está probando, qué resultado se espera y qué comportamiento se está validando.

No probar errores

Muchas veces se prueban solo los resultados correctos, pero no las situaciones problemáticas. Validar errores también forma parte del comportamiento esperado de una función.

Por ejemplo, si una función debe lanzar un error cuando falta un parámetro obligatorio, ese comportamiento también debería tener su propio test.

Mezclar demasiada lógica dentro del test

Si dentro del test hay demasiados cálculos, condicionales o transformaciones, quizá el test se está volviendo más complejo que el propio código probado.

Un test debe ser simple: preparar datos, ejecutar la función y comprobar el resultado.

Una estructura muy habitual es la conocida como Arrange, Act, Assert:

  • Preparar los datos.
  • Ejecutar la acción.
  • Comprobar el resultado.

Aunque no es obligatorio seguirla siempre de forma estricta, puede ayudar mucho a mantener los tests ordenados.

Abusar de mocks innecesarios

Los mocks pueden ser útiles, sobre todo cuando hay dependencias externas. Pero si se usan sin necesidad, pueden hacer que las pruebas sean más difíciles de mantener.

En pruebas unitarias, lo ideal es aislar la lógica, pero sin convertir cada test en una simulación artificial imposible de entender.

Cómo integrar las pruebas unitarias en el flujo de trabajo

Las pruebas unitarias son más útiles cuando forman parte del día a día del proyecto.

Lo más recomendable es ejecutar los tests:

  • Antes de hacer un commit importante.
  • Antes de abrir una pull request.
  • Después de refactorizar una función.
  • Antes de desplegar a producción.
  • Dentro de un flujo de integración continua.

Por ejemplo, en un proyecto con GitHub Actions podríamos configurar un workflow para ejecutar npm test automáticamente cada vez que se suben cambios al repositorio.

Esto permite detectar errores antes de que lleguen a producción y ayuda a mantener un estándar mínimo de calidad en el código.

Si estás trabajando en proyectos que se despliegan en repositorios públicos o privados, también puedes ampliar esta parte con una guía sobre desplegar proyectos en GitHub Pages, especialmente si quieres conectar testing, automatización y publicación.

Testing e integración continua

Una de las mejores formas de sacar partido a las pruebas unitarias es integrarlas en un proceso de integración continua.

Esto significa que los tests se ejecutan automáticamente cuando se suben cambios al repositorio. Así, si una modificación rompe una funcionalidad existente, el equipo puede detectarlo antes de fusionar el código o desplegarlo.

En proyectos pequeños puede parecer innecesario, pero a medida que el código crece, automatizar las pruebas se convierte en una ayuda enorme.

No se trata solo de ahorrar tiempo. También se trata de reducir la incertidumbre.

Mocha y Chai frente a otras herramientas de testing

Es normal preguntarse si merece la pena aprender Mocha y Chai cuando existen alternativas más recientes.

La respuesta depende del proyecto.

Mocha y Chai destacan por su flexibilidad. No intentan resolverlo todo de una sola vez, sino que permiten construir un entorno de testing a medida. Esto puede ser ideal para proyectos Node.js, librerías o aplicaciones donde queremos controlar cada pieza del ecosistema.

Herramientas como Jest o Vitest suelen ofrecer una experiencia más integrada, con aserciones, mocks y cobertura en un solo paquete. Esto puede ser muy cómodo, especialmente en proyectos frontend modernos.

Sin embargo, aprender Mocha y Chai sigue siendo muy útil porque ayuda a comprender mejor los fundamentos del testing en JavaScript: estructura de pruebas, aserciones, casos límite, pruebas asíncronas y separación de responsabilidades.

Entonces, ¿cuál debería elegir?

Si estás empezando desde cero y quieres entender bien las bases, Mocha y Chai son una combinación muy didáctica.

Si trabajas en un proyecto ya configurado con Jest o Vitest, probablemente tenga sentido seguir con la herramienta existente para mantener coherencia dentro del equipo.

Lo importante no es elegir la herramienta más popular, sino crear una cultura de pruebas que ayude a mejorar el código y reducir errores.

FAQs sobre pruebas unitarias con Mocha y Chai

¿Mocha y Chai sirven solo para Node.js?

No. Mocha puede ejecutarse tanto en Node.js como en navegador, y Chai también puede utilizarse en ambos entornos. Aun así, su uso más habitual suele estar en proyectos JavaScript y Node.js, especialmente para probar lógica de negocio, utilidades, servicios y módulos independientes.

¿Cuál es la diferencia entre Mocha y Chai?

Mocha es el framework que organiza y ejecuta las pruebas. Chai es la librería que permite escribir las aserciones. Dicho de otra forma, Mocha define la estructura del test y Chai comprueba si el resultado obtenido coincide con el resultado esperado.

Por eso se utilizan tan bien juntos: cada herramienta cumple una función clara.

¿Es mejor usar Mocha y Chai o Jest?

No hay una respuesta universal. Jest ofrece una experiencia más integrada y suele utilizarse mucho en proyectos frontend, especialmente con React. Mocha y Chai ofrecen más flexibilidad y permiten configurar el entorno de testing de forma más modular.

Si buscas una solución todo en uno, Jest o Vitest pueden ser opciones cómodas. Si prefieres controlar mejor cada parte del entorno de pruebas, Mocha y Chai siguen siendo una combinación muy sólida.

Probar con intención: la base de un código más confiable

Las pruebas unitarias con Mocha y Chai no son solo una práctica técnica. También son una forma de trabajar con más claridad, más seguridad y menos miedo a cambiar el código.

Cuando un proyecto no tiene tests, cada modificación puede generar dudas: “¿habré roto algo?”, “¿seguirá funcionando este cálculo?”, “¿qué pasa si cambio esta función?”. En cambio, cuando contamos con una buena base de pruebas unitarias, el código se vuelve más fácil de mantener y evolucionar.

Mocha y Chai ofrecen una combinación sencilla, flexible y potente para empezar a escribir tests en JavaScript. Mocha nos da la estructura. Chai nos da la expresividad. Juntas, ambas herramientas nos permiten construir pruebas claras, legibles y enfocadas en el comportamiento real del código.

La clave no está en probarlo absolutamente todo, sino en probar lo importante: las reglas de negocio, los casos límite, los errores esperados y aquellas funciones que sostienen partes críticas de la aplicación.

En desarrollo web, la calidad no aparece al final del proceso. Se construye poco a poco, decisión a decisión. Y escribir buenas pruebas unitarias es una de esas decisiones que, aunque al principio parezca pequeña, puede marcar una gran diferencia en la vida útil de un proyecto.

Desplegar proyectos en GitHub Pages

Posted on by marta

Github Pages nos permite generar sitios web estáticos o serverless de proyectos a partir de nuestros repositorios publicados en Github de forma fácil y gratuita.

Para empezar es necesario tener una cuenta de usuario en la plataforma de Github y tener instalado Git en nuestra máquina.

Crear repositorio

Para el ejemplo crearemos un nuevo repositorio desde github.com/new.

Podemos hacer un clonado del proyecto  o irnos a nuestro editor de código, crear un directorio, añadir contenido y subir los cambios al nuevo repositorio. Vamos a hacer lo segundo.

Creamos un nuevo directorio para nuestro proyecto y accedemos al mismo.

Incluir contenido al proyecto

> mkdir desplegar-en-githubpages
> cd desplegar-en-githubpages

Para el ejemplo crearemos un archivo index.html desde nuestro editor de código en el cual incluiremos una estructura de html5 básica rápidamente mediante Emmet.

Obtenemos la siguiente estructura a la que añadiremos un mensaje de Hola Mundo que se pintará por pantalla.

Volvemos al terminal e inicializamos git.

> git init

Incluimos nuestros cambios por primera vez.

> git add index.html
> git commit -m "First Commit"
> git branch -M main
> git remote add origin https://github.com/[usuario]^*/[repositorio].git
> git push -u origin main

Habilitar GitHub Pages y desplegar proyecto

Volvemos a la página de GitHub y accedemos a la sección Pages de los Settings del repositorio. Seleccionamos una rama para habilitar GitHub Pages.

En la barra lateral de nuestro repositorio ahora podemos ver la sección de Enviroments y github-pages desplegando.

Si hacemos clic sobre la opción del entorno de GitHub Pages accedemos al historial desde donde podemos verificar si el despliegue se ha realizado y ver el proyecto desplegado en [usuario].github.io/[repositorio]

Estructura básica de HTML5 con CSS Grid Layout

Posted on by marta

Esquema visual de una estructura web con CSS Grid, mostrando distribución en escritorio y móvil.

Crear una estructura HTML5 con CSS Grid es una de las formas más claras y mantenibles de empezar a maquetar una página web moderna. Si estás aprendiendo desarrollo frontend, seguramente ya te hayas encontrado con etiquetas como header, main, aside o footer, y también con propiedades como display: grid, grid-template-columns o grid-template-areas.

El problema es que muchas veces estos conceptos se explican por separado. Por un lado, se habla de la estructura básica de HTML5. Por otro, se muestran ejemplos aislados de CSS Grid Layout. Sin embargo, lo realmente útil es entender cómo se combinan ambas partes para construir una página sencilla, semántica y adaptable a distintos tamaños de pantalla.

En este artículo vamos a ver cómo maquetar con CSS Grid una estructura básica formada por cabecera, contenido principal, barra lateral y pie de página. Lo haremos paso a paso, explicando el HTML, el CSS, la lógica de las áreas del grid y cómo convertir el diseño en un layout responsive con CSS Grid.

La idea no es solo copiar y pegar código, sino entender qué está pasando en cada parte para que puedas adaptar esta base a tus propios proyectos.

Qué vamos a construir con HTML5 y CSS Grid Layout

Vamos a crear una estructura clásica de página web compuesta por cuatro zonas principales:

  • una cabecera o header;
  • una zona de contenido principal con main;
  • una barra lateral con aside;
  • un pie de página con footer.

Visualmente, en escritorio tendremos una estructura parecida a esta:

+-----------------------------+
|           HEADER            |
+------------------+----------+
|     CONTENT      | SIDEBAR  |
+------------------+----------+
|           FOOTER            |
+-----------------------------+

En pantallas pequeñas, como móviles, reorganizaremos la estructura en una sola columna:

+----------+
| HEADER   |
+----------+
| CONTENT  |
+----------+
| SIDEBAR  |
+----------+
| FOOTER   |
+----------+

Esta es una de las ventajas principales de CSS Grid: permite definir una estructura visual clara sin alterar el orden semántico del HTML.

Es decir, podemos mantener un documento bien organizado para personas, navegadores, lectores de pantalla y buscadores, mientras adaptamos su distribución visual mediante CSS. Para reforzar esta parte desde la base, también puedes leer el artículo sobre HTML semántico y accesibilidad web, porque la estructura del documento influye directamente en cómo se interpreta una página.

Por qué usar una estructura básica HTML5

Antes de escribir el CSS, merece la pena detenernos en el HTML. A veces se piensa que maquetar consiste simplemente en colocar cajas en pantalla, pero una buena página web empieza mucho antes: empieza con una estructura clara.

HTML5 introdujo etiquetas semánticas que ayudan a describir mejor las partes de una página. En lugar de usar únicamente div, podemos utilizar elementos que tienen significado propio.

HTML5 no solo organiza: también comunica

Cuando usamos una etiqueta como main, estamos indicando que ahí se encuentra el contenido principal de la página. Cuando usamos aside, estamos diciendo que ese contenido es complementario. Y cuando usamos footer, estamos marcando una zona de cierre o información secundaria.

Esto mejora varios aspectos:

  • la accesibilidad, porque las tecnologías de asistencia pueden interpretar mejor la página;
  • la legibilidad del código, porque otros desarrolladores entienden antes la estructura;
  • el SEO técnico, porque el contenido principal queda mejor identificado;
  • el mantenimiento, porque cada zona tiene una responsabilidad clara.

Dicho de otra manera: una buena estructura básica HTML5 no consiste en llenar la página de etiquetas modernas, sino en elegir las etiquetas adecuadas para cada bloque de contenido.

El error de usar div para todo

Durante mucho tiempo, muchas maquetas web se construían casi exclusivamente con div. Técnicamente funcionaba, pero el resultado era menos expresivo:

<div class="header"></div>
<div class="content"></div>
<div class="sidebar"></div>
<div class="footer"></div>

Este código puede ser válido, pero no comunica tanto como este:

<header></header>
<main></main>
<aside></aside>
<footer></footer>

Ambas versiones pueden verse igual con CSS, pero no significan lo mismo. La segunda versión es más clara, más semántica y más alineada con las buenas prácticas actuales.

Semántica no significa complicar el código

Un error frecuente es pensar que usar HTML semántico hace que el código sea más complejo. En realidad, suele ocurrir lo contrario. Cuando cada bloque tiene una etiqueta adecuada, el documento se entiende mejor y resulta más fácil de mantener.

La semántica no añade decoración ni comportamiento visual por sí misma. Su función es dar significado. Después, CSS se encarga de decidir cómo se presenta ese contenido en pantalla.

Código HTML de una estructura básica con CSS Grid

Empecemos con el HTML completo. La estructura será sencilla para que puedas entender bien la relación entre cada elemento y su área dentro del grid.

<div class="layout">
  <header class="header">
    <h1>Mi sitio web</h1>
  </header>

  <main class="content">
    <h2>Contenido principal</h2>
    <p>
      Esta es la zona principal de la página. Aquí iría el contenido más importante:
      artículos, servicios, productos, documentación o cualquier información central.
    </p>
  </main>

  <aside class="sidebar">
    <h2>Barra lateral</h2>
    <p>
      Este espacio puede utilizarse para enlaces relacionados, categorías,
      información complementaria o llamadas a la acción.
    </p>
  </aside>

  <footer class="footer">
    <p>© 2026 Mi sitio web. Todos los derechos reservados.</p>
  </footer>
</div>

Este ejemplo ya contiene una base sólida. Tenemos un contenedor general llamado .layout y dentro de él cuatro áreas principales.

Qué representa cada etiqueta

Header

La etiqueta header representa la cabecera de la página o de una sección. Puede incluir el logotipo, el título del sitio, un menú de navegación o una introducción.

En este ejemplo contiene un h1, pero en una página real también podría incluir una navegación principal.

Main

La etiqueta main representa el contenido principal del documento. Es importante recordar que, por norma general, debería haber un único main por página.

Aquí es donde colocaríamos el contenido más relevante. En un blog, por ejemplo, sería el artículo. En una landing, podría ser la propuesta principal de valor.

Aside

La etiqueta aside se utiliza para contenido complementario. No debería contener información imprescindible para entender la página, sino elementos relacionados o secundarios.

Por ejemplo, una barra lateral puede incluir enlaces a artículos relacionados, categorías, filtros, anuncios, una biografía del autor o llamadas a la acción.

La etiqueta footer suele contener información de cierre: derechos de autor, enlaces legales, contacto, redes sociales o navegación secundaria.

No tiene por qué aparecer solo al final de una página completa. También puede existir un footer dentro de una tarjeta, artículo o sección, siempre que tenga sentido semántico.

Cómo maquetar con CSS Grid paso a paso

Una vez que tenemos el HTML, llega el momento de aplicar CSS. Aquí es donde entra en juego CSS Grid Layout.

CSS Grid nos permite crear filas y columnas de forma precisa. A diferencia de otros sistemas de maquetación más antiguos, no necesitamos usar float, tablas ni soluciones forzadas para construir una estructura de página.

Activar CSS Grid en el contenedor

La primera propiedad importante es display: grid.

.layout {
  display: grid;
}

Con esta línea convertimos .layout en un contenedor grid. Sus hijos directos —header, main, aside y footer— pasan a comportarse como elementos de esa cuadrícula.

Pero, por ahora, el navegador todavía no sabe cómo queremos repartir las zonas. Para eso necesitamos definir columnas, filas y áreas.

Definir columnas y filas

Podemos empezar con una estructura de dos columnas:

.layout {
  display: grid;
  grid-template-columns: 1fr 280px;
}

Aquí estamos diciendo que la primera columna ocupará el espacio disponible gracias a 1fr, mientras que la segunda tendrá un ancho fijo de 280px.

La unidad fr significa fracción del espacio disponible. Es muy útil porque nos permite crear diseños flexibles sin depender siempre de porcentajes rígidos.

También podemos definir las filas:

.layout {
  display: grid;
  grid-template-columns: 1fr 280px;
  grid-template-rows: auto 1fr auto;
}

En este caso, la primera fila mide lo que necesite el header, la segunda ocupa el espacio principal disponible y la tercera mide lo que necesite el footer.

Usar grid-template-areas

Una de las formas más claras de crear una estructura HTML5 con CSS Grid es utilizar grid-template-areas.

Esta propiedad permite nombrar zonas del layout y dibujarlas de forma visual en el CSS.

.layout {
  display: grid;
  min-height: 100vh;
  grid-template-columns: 1fr 280px;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header header"
    "content sidebar"
    "footer footer";
  gap: 1rem;
}

Este bloque es muy expresivo. Podemos leerlo casi como un esquema:

"header header"
"content sidebar"
"footer footer"

La cabecera ocupa dos columnas. El contenido principal ocupa la primera columna. La barra lateral ocupa la segunda. El pie de página vuelve a ocupar todo el ancho.

Esta es una de las razones por las que grid-template-areas resulta tan útil en layouts básicos: permite entender la estructura de un vistazo.

Asignar cada elemento HTML a su área del grid

Una vez definidas las áreas, necesitamos decirle a cada elemento dónde debe colocarse.

.header {
  grid-area: header;
}

.content {
  grid-area: content;
}

.sidebar {
  grid-area: sidebar;
}

.footer {
  grid-area: footer;
}

Cada valor de grid-area debe coincidir con uno de los nombres definidos en grid-template-areas.

Es importante que los nombres sean claros. Podrías usar nombres como top, left o box1, pero no serían tan descriptivos. En cambio, header, content, sidebar y footer explican perfectamente la función de cada zona.

CSS completo del layout

Uniendo todo, tendríamos este CSS base:

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  font-family: system-ui, sans-serif;
  line-height: 1.5;
  color: #222;
  background-color: #f5f5f5;
}

.layout {
  display: grid;
  min-height: 100vh;
  grid-template-columns: 1fr 280px;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header header"
    "content sidebar"
    "footer footer";
  gap: 1rem;
  padding: 1rem;
}

.header,
.content,
.sidebar,
.footer {
  padding: 1.5rem;
  border-radius: 0.75rem;
  background-color: #ffffff;
}

.header {
  grid-area: header;
}

.content {
  grid-area: content;
}

.sidebar {
  grid-area: sidebar;
}

.footer {
  grid-area: footer;
}

Este ejemplo ya crea una maqueta funcional, clara y fácil de modificar. No es un diseño visual complejo, pero sí una base muy útil para entender cómo maquetar con CSS Grid de forma ordenada.

Después puedes añadir microinteracciones o pequeños efectos visuales al diseño con recursos como las animaciones CSS o revisar la diferencia entre transition y animation en CSS. Eso sí: primero conviene tener una estructura sólida; los efectos deberían reforzar la experiencia, no esconder una maqueta confusa.

Cómo crear un layout responsive con CSS Grid

Hasta ahora tenemos una estructura pensada para pantallas medianas o grandes. Pero una web actual debe funcionar correctamente en móvil, tablet y escritorio.

Aquí entra otro punto importante: un layout responsive con CSS Grid no tiene por qué ser complicado. Podemos reorganizar las áreas modificando grid-template-areas dentro de una media query.

Adaptar la estructura a pantallas pequeñas

En móvil, normalmente no queremos mantener dos columnas. Una barra lateral al lado del contenido puede quedarse demasiado estrecha y generar problemas de lectura.

Por eso podemos pasar a una sola columna:

@media (max-width: 768px) {
  .layout {
    grid-template-columns: 1fr;
    grid-template-rows: auto;
    grid-template-areas:
      "header"
      "content"
      "sidebar"
      "footer";
  }
}

Con este cambio, todos los bloques se colocan uno debajo del otro.

Lo interesante es que no hemos tenido que tocar el HTML. Solo hemos cambiado la distribución visual desde CSS.

Por qué esto es importante

Separar estructura y presentación es una de las ideas más importantes del desarrollo web.

El HTML debe mantener un orden lógico. El CSS puede encargarse de adaptar la presentación según el espacio disponible.

Esto evita un error muy común: reorganizar el HTML solo para conseguir un efecto visual concreto. Si hacemos eso, podemos perjudicar la accesibilidad, la lectura del contenido y el mantenimiento del proyecto.

Este mismo enfoque también es útil cuando trabajamos con ilustraciones, tarjetas o bloques visuales que deben adaptarse a distintos tamaños de pantalla. Para profundizar en esa idea desde una perspectiva más visual, puedes leer el artículo sobre cómo dibujar con CSS responsive.

Buenas prácticas al trabajar con CSS Grid Layout

CSS Grid es muy potente, pero conviene usarlo con criterio. No se trata de convertir cualquier pequeño componente en una cuadrícula compleja, sino de elegir la herramienta adecuada para cada caso.

Mantén el HTML en un orden lógico

Aunque CSS Grid permite colocar elementos visualmente en posiciones diferentes, no deberíamos abusar de esa capacidad.

Por ejemplo, si el contenido principal aparece antes que la barra lateral en el HTML, lo habitual es mantener ese orden también en la experiencia de lectura. Esto ayuda especialmente a quienes navegan con teclado o usan lectores de pantalla.

El diseño visual no debería contradecir la lógica del documento.

Evita alturas fijas innecesarias

En muchos ejemplos antiguos de CSS Grid se usan alturas fijas como height: 500px. Para una demostración rápida puede servir, pero en una web real suele ser mejor usar soluciones más flexibles.

Por ejemplo:

min-height: 100vh;

Esta propiedad permite que el layout ocupe al menos toda la altura de la ventana, pero sin impedir que crezca si el contenido necesita más espacio.

Usa nombres de áreas fáciles de entender

grid-template-areas funciona mejor cuando los nombres de las áreas son claros.

Mejor esto:

grid-template-areas:
  "header header"
  "content sidebar"
  "footer footer";

Que esto:

grid-template-areas:
  "a a"
  "b c"
  "d d";

La segunda versión funciona, pero obliga a interpretar el código. La primera se entiende prácticamente sola.

No uses CSS Grid para absolutamente todo

CSS Grid es ideal para layouts en dos dimensiones: filas y columnas. Sin embargo, para alinear elementos en una sola dirección, muchas veces Flexbox sigue siendo una opción más sencilla.

Por ejemplo, para distribuir enlaces dentro de un menú horizontal, probablemente Flexbox sea suficiente. Para construir la estructura general de una página, CSS Grid suele ser más claro.

CSS Grid vs Flexbox: cuándo usar cada uno

Una duda habitual al aprender maquetación moderna es cuándo usar CSS Grid y cuándo usar Flexbox.

No hay una única respuesta, pero sí una regla práctica bastante útil.

Usa CSS Grid para la estructura general

CSS Grid funciona muy bien cuando necesitas controlar filas y columnas al mismo tiempo. Por ejemplo:

  • layouts de página;
  • galerías;
  • dashboards;
  • estructuras con sidebar;
  • tarjetas distribuidas en varias columnas;
  • zonas visuales con áreas diferenciadas.

En este artículo lo usamos para definir una estructura completa: cabecera, contenido, barra lateral y footer.

Usa Flexbox para alineaciones internas

Flexbox suele ser más cómodo cuando trabajas en una sola dirección: fila o columna.

Por ejemplo:

  • alinear elementos de navegación;
  • centrar un botón con un icono;
  • distribuir elementos dentro de una tarjeta;
  • separar contenido con justify-content: space-between;
  • ordenar elementos pequeños dentro de un componente.

En proyectos reales, lo habitual es combinar ambas herramientas. Puedes usar CSS Grid para la estructura principal y Flexbox para detalles internos.

Ejemplo completo: HTML5 y CSS Grid Layout

A continuación tienes el ejemplo completo, listo para probar.

HTML

<div class="layout">
  <header class="header">
    <h1>Mi sitio web</h1>
  </header>

  <main class="content">
    <h2>Contenido principal</h2>
    <p>
      Esta es la zona principal de la página. Aquí puedes colocar el contenido
      más importante, como un artículo, una presentación de servicios o una
      página informativa.
    </p>
  </main>

  <aside class="sidebar">
    <h2>Barra lateral</h2>
    <p>
      Aquí puedes añadir enlaces relacionados, categorías, recursos destacados
      o cualquier información complementaria.
    </p>
  </aside>

  <footer class="footer">
    <p>© 2026 Mi sitio web. Todos los derechos reservados.</p>
  </footer>
</div>

CSS

* {
  box-sizing: border-box;
}

body {
  margin: 0;
  font-family: system-ui, sans-serif;
  line-height: 1.5;
  color: #222;
  background-color: #f5f5f5;
}

.layout {
  display: grid;
  min-height: 100vh;
  grid-template-columns: 1fr 280px;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header header"
    "content sidebar"
    "footer footer";
  gap: 1rem;
  padding: 1rem;
}

.header,
.content,
.sidebar,
.footer {
  padding: 1.5rem;
  border-radius: 0.75rem;
  background-color: #ffffff;
}

.header {
  grid-area: header;
}

.content {
  grid-area: content;
}

.sidebar {
  grid-area: sidebar;
}

.footer {
  grid-area: footer;
}

@media (max-width: 768px) {
  .layout {
    grid-template-columns: 1fr;
    grid-template-rows: auto;
    grid-template-areas:
      "header"
      "content"
      "sidebar"
      "footer";
  }
}

Este ejemplo resume la base de una estructura HTML5 con CSS Grid moderna: semántica, legible, responsive y fácil de ampliar.

Errores comunes al maquetar con CSS Grid

Aunque CSS Grid simplifica mucho la creación de layouts, hay algunos errores que conviene evitar desde el principio.

Confundir Grid con una solución mágica

CSS Grid es potente, pero no sustituye la necesidad de pensar la estructura. Antes de escribir CSS, conviene preguntarse:

  • ¿cuál es el contenido principal?
  • ¿qué contenido es complementario?
  • ¿qué orden tiene sentido en el HTML?
  • ¿cómo debería adaptarse en móvil?
  • ¿qué bloques deben ocupar más espacio?

Una buena maqueta no empieza con propiedades CSS, sino con decisiones de contenido.

Crear demasiadas áreas

grid-template-areas es muy cómodo, pero no hace falta usarlo para cada pequeño elemento. Es ideal para zonas grandes del layout, no necesariamente para cada botón, icono o texto interno.

Si el grid empieza a parecer un mapa imposible de mantener, quizá estás intentando resolver demasiado desde una sola cuadrícula.

Olvidar el responsive

Un diseño de dos columnas puede verse perfecto en escritorio y romperse por completo en móvil. Por eso es importante probar pronto cómo se comporta el layout en pantallas pequeñas.

En muchos casos, la solución será tan sencilla como cambiar a una columna, pero no deberíamos dejar esa decisión para el final.

Pensar solo en lo visual

Maquetar no consiste únicamente en colocar cajas bonitas. También implica cuidar el orden del contenido, la accesibilidad, la legibilidad y la experiencia de uso.

Una estructura puede verse bien y, aun así, estar mal organizada. Por eso conviene trabajar siempre con HTML semántico y CSS mantenible.

Cómo ampliar esta estructura en un proyecto real

El ejemplo que hemos visto es básico, pero puede crecer fácilmente.

Podrías añadir una navegación dentro del header:

<header class="header">
  <h1>Mi sitio web</h1>
  <nav>
    <a href="/">Inicio</a>
    <a href="/blog">Blog</a>
    <a href="/contacto">Contacto</a>
  </nav>
</header>

También podrías transformar el main en una zona de artículos, tarjetas o secciones internas.

<main class="content">
  <article>
    <h2>Título del artículo</h2>
    <p>Contenido del artículo...</p>
  </article>
</main>

O podrías usar el aside para mostrar contenido relacionado:

<aside class="sidebar">
  <h2>También te puede interesar</h2>
  <ul>
    <li><a href="#">Guía de HTML semántico</a></li>
    <li><a href="#">Introducción a CSS Grid</a></li>
    <li><a href="#">Cómo crear layouts responsive</a></li>
  </ul>
</aside>

La clave está en conservar una estructura clara. Cuanto más crece una página, más importante se vuelve que cada bloque tenga una función reconocible.

Preguntas frecuentes sobre estructura HTML5 con CSS Grid

¿Qué es una estructura HTML5 con CSS Grid?

Una estructura HTML5 con CSS Grid es una forma de organizar una página usando etiquetas semánticas de HTML5, como header, main, aside y footer, junto con CSS Grid para distribuir visualmente esas zonas en filas y columnas.

La ventaja es que separa muy bien el significado del contenido y su presentación visual. HTML define qué es cada parte. CSS Grid define dónde y cómo se muestra.

¿Es mejor usar CSS Grid o Flexbox para maquetar una página?

Para la estructura general de una página, normalmente CSS Grid Layout resulta más adecuado porque permite trabajar con filas y columnas al mismo tiempo. Para alinear elementos internos en una sola dirección, Flexbox suele ser más sencillo.

En la práctica, no tienes que elegir solo uno. Lo habitual es usar CSS Grid para el layout principal y Flexbox para componentes internos, como menús, botones o tarjetas.

¿Se puede crear un layout responsive con CSS Grid?

Sí. De hecho, crear un layout responsive con CSS Grid suele ser bastante limpio. Puedes definir una estructura de dos columnas para escritorio y cambiarla a una sola columna en móvil mediante una media query.

La propiedad grid-template-areas facilita mucho este proceso porque permite reorganizar visualmente las zonas sin modificar el HTML.

Una base sencilla para construir layouts más claros

Aprender a maquetar con CSS Grid no consiste solo en memorizar propiedades. Lo importante es entender cómo se relacionan la estructura, el contenido y la presentación visual.

HTML5 nos ayuda a construir documentos con significado. CSS Grid nos permite distribuir ese contenido con precisión. Cuando combinamos ambas herramientas, obtenemos layouts más claros, más accesibles y más fáciles de mantener.

Una estructura básica HTML5 con cabecera, contenido principal, barra lateral y footer puede parecer sencilla, pero es una base excelente para comprender cómo se organizan muchas páginas reales. A partir de ahí, puedes añadir navegación, tarjetas, secciones, componentes, contenido dinámico o estilos más elaborados.

La clave está en no empezar por la decoración, sino por la arquitectura del contenido. Primero define qué es cada bloque. Después decide cómo debe comportarse en pantalla. Y, por último, ajusta los detalles visuales.

CSS Grid no solo sirve para crear diseños más modernos. Bien utilizado, también te ayuda a pensar mejor la estructura de una página web.

Para el post he simplificado el código del estilo en CSS pero puedes verlo también en SCSS dentro de mi repositorio de Github y también una demo en Github Pages.