Pruebas unitarias: qué son, cómo se escriben y por qué evitan errores
Qué es una prueba unitaria, cómo se escribe paso a paso, qué herramientas se usan en cada lenguaje y qué errores conviene evitar. La guía que explica el nombre de FireUnit.
Revisado el 14 de octubre de 2026 · 6 min
Las pruebas unitarias son pequeños programas que comprueban, de forma automática, que una parte concreta del código hace exactamente lo que debe. Se escriben una vez y se ejecutan cientos de veces: cada vez que alguien cambia algo, avisan en segundos si se ha roto lo que antes funcionaba. Son la primera red de seguridad de cualquier proyecto de software y, de paso, la razón de que este blog se llame como se llama.
Qué es una prueba unitaria
Una prueba unitaria aísla la unidad más pequeña que se puede probar (normalmente una función o un método) y verifica su resultado con unos datos de entrada conocidos. Si la función calcular_iva(100) debe devolver 121, la prueba la llama con 100 y comprueba que el resultado es 121. Si alguien cambia el tipo de IVA por error, la prueba falla y lo dice.
Tres rasgos la distinguen de otras comprobaciones:
- Es pequeña: prueba una sola cosa y lo hace en milisegundos.
- Está aislada: no depende de una base de datos, de internet ni del orden en que se ejecute.
- Es automática: nadie tiene que mirar la pantalla para saber si ha pasado; el resultado es verde o rojo.
De FireUnit a hoy: el origen del nombre
En 2008, John Resig (el creador de jQuery) y Jan Odvarko publicaron FireUnit, una extensión para Firefox que se integraba en Firebug, la herramienta de depuración más usada de la época. Permitía escribir pruebas unitarias de JavaScript y ver los resultados en una pestaña del propio navegador, algo poco habitual entonces.
Firebug dejó de desarrollarse en 2017, cuando sus funciones pasaron a las herramientas para desarrolladores que Firefox trae de serie, y los complementos antiguos dejaron de funcionar con el cambio a las extensiones de Firefox modernas. El dominio quedó libre y hoy alberga este blog, que conserva la idea: comprobar las cosas antes de darlas por buenas.

Pruebas unitarias frente a otros tipos de test
Las pruebas unitarias forman la base de la llamada pirámide de pruebas: muchas pruebas pequeñas y rápidas abajo, menos pruebas grandes y lentas arriba.
| Tipo | Qué comprueba | Velocidad |
|---|---|---|
| Unitaria | Una función o clase aislada, con datos controlados. | Milisegundos |
| De integración | Que varias piezas funcionan juntas: el código y la base de datos, dos servicios entre sí. | Segundos |
| De extremo a extremo | Un recorrido completo como lo haría una persona: entrar, rellenar un formulario, pagar. | Minutos |
| Manual o exploratoria | Lo que una persona detecta usando la aplicación: textos confusos, flujos raros. | Horas |
Las unitarias no sustituyen a las demás, pero son las más baratas de escribir y mantener, y las que antes avisan de un problema.
Cómo se escribe una prueba unitaria: el patrón AAA
Casi todas las pruebas unitarias siguen la misma estructura en tres pasos, conocida como AAA por sus nombres en inglés:
- Preparar (Arrange): crear los datos y el estado de partida.
- Actuar (Act): llamar a la función que se quiere probar.
- Comprobar (Assert): verificar que el resultado es el esperado.
Ejemplo de pruebas unitarias en Python
Con pytest, la herramienta más extendida en Python, una prueba es una función cuyo nombre empieza por test_:
def precio_con_iva(base, tipo=0.21):
return round(base * (1 + tipo), 2)
def test_aplica_el_iva_general():
base = 100 # preparar
total = precio_con_iva(base) # actuar
assert total == 121.0 # comprobar
def test_admite_el_tipo_reducido():
assert precio_con_iva(100, 0.10) == 110.0
Se ejecutan escribiendo pytest en la terminal. Si alguien cambia la función y el resultado deja de ser 121, la prueba marca el fallo y muestra qué valor ha recibido.
Ejemplo en JavaScript
En JavaScript las opciones más usadas son Jest y Vitest, con una sintaxis casi idéntica:
import { test, expect } from 'vitest';
import { slug } from './slug.js';
test('convierte un título en una dirección limpia', () => {
expect(slug('Pruebas Unitarias 101')).toBe('pruebas-unitarias-101');
});
Herramientas según el lenguaje
- Java: JUnit, el marco que popularizó el estilo «xUnit».
- Python: pytest o
unittest, incluido en la biblioteca estándar. - JavaScript y TypeScript: Jest, Vitest o el ejecutor de pruebas que trae Node.js.
- PHP: PHPUnit, también el que usa WordPress para su propio código.
- C#: xUnit.net, NUnit o MSTest.
Buenas prácticas: los principios FIRST
Una buena prueba unitaria cumple cinco condiciones que se resumen en la sigla FIRST:
- Rápida (Fast): si tarda, nadie la ejecutará a menudo.
- Independiente (Isolated): no depende de otras pruebas ni del orden en que se lancen.
- Repetible (Repeatable): da el mismo resultado en cualquier ordenador y a cualquier hora.
- Autoverificable (Self-validating): dice por sí sola si ha pasado o fallado.
- Oportuna (Timely): se escribe a la vez que el código, no meses después.
Para aislar una función que normalmente habla con una base de datos o una API externa se usan dobles de prueba (mocks, stubs): sustitutos que devuelven respuestas fijas y permiten comprobar la lógica sin depender de servicios reales.

Desarrollo guiado por pruebas (TDD)
Algunos equipos dan la vuelta al orden habitual y escriben la prueba antes que el código. Es el desarrollo guiado por pruebas, que funciona en ciclos cortos de tres pasos: rojo (escribir una prueba que falla), verde (escribir el código mínimo para que pase) y refactorizar (mejorar el código sin romper la prueba). Obliga a pensar primero en qué debe hacer cada función y deja el proyecto cubierto de pruebas desde el primer día.
Pruebas unitarias con IA
Los asistentes de programación basados en IA pueden proponer pruebas unitarias a partir de una función en segundos, y son útiles para cubrir casos repetitivos o detectar entradas límite que se habían pasado por alto. Conviene revisarlas como cualquier otro código: una prueba generada puede limitarse a confirmar lo que la función ya hace, errores incluidos, en lugar de comprobar lo que debería hacer.
Errores frecuentes al empezar
- Probar demasiado a la vez: si una prueba falla y comprueba diez cosas, no sabrás cuál se ha roto.
- Perseguir el 100 % de cobertura: la cobertura indica qué líneas se ejecutan, no si las comprobaciones tienen sentido.
- Pruebas frágiles: las que fallan al cambiar detalles internos sin que cambie el resultado obligan a reescribirlas sin motivo.
- Depender de la fecha o de la red: una prueba que hoy pasa y mañana no deja de ser fiable.
- No ejecutarlas: lo ideal es lanzarlas automáticamente en cada cambio con un sistema de integración continua.
Preguntas frecuentes
¿Qué es una prueba unitaria, en una frase?
Un pequeño programa que comprueba automáticamente que una función concreta devuelve el resultado esperado con unos datos conocidos.
¿Quién escribe las pruebas unitarias?
Normalmente la misma persona que escribe el código, a la vez que lo desarrolla. Los equipos de calidad suelen centrarse en las pruebas de integración y de extremo a extremo.
¿Qué diferencia hay entre test unitario y prueba unitaria?
Ninguna: «test unitario» es el calco del inglés unit test y «prueba unitaria» su traducción. Ambos nombres se usan indistintamente.
¿Cuántas pruebas unitarias hay que escribir?
Las suficientes para cubrir el comportamiento importante de cada función: el caso normal, los casos límite (cero, vacío, valores máximos) y las entradas no válidas.
¿Las pruebas unitarias ralentizan el desarrollo?
Al principio suponen algo más de trabajo, pero ahorran mucho tiempo después: los errores aparecen en segundos, en lugar de descubrirse semanas más tarde en producción.