Las pruebas unitarias verifican una a una las partes más pequeñas de un programa antes de que se combinen en funcionalidades. Los desarrolladores escriben cada prueba unitaria como un breve fragmento de código que se ejecuta automáticamente en segundos. Como cada prueba examina una sola parte de forma aislada, un fallo señala directamente el código defectuoso.
De todas las comprobaciones por las que pasa un producto antes de su lanzamiento, las pruebas unitarias son las que un equipo de QA no suele ejecutar, ya que ese trabajo corresponde a los desarrolladores. Una vez que cada unidad funciona correctamente, la automatización de QA puede centrarse en lo que las pruebas unitarias no ven: cómo funcionan las partes juntas en funcionalidades reales.
¿Qué son las pruebas unitarias y qué comprueban?
El International Software Testing Qualifications Board (ISTQB) define la prueba unitaria como el nivel de prueba que se concentra en evaluar «la parte más pequeña del código que puede ser objeto de prueba de forma aislada». En la mayoría de los programas, esa parte es una función, un bloque breve de código que recibe unos datos de entrada y devuelve un resultado.
Aislar significa separar la unidad de la base de datos, del proveedor de pagos y del servicio de inicio de sesión. Los desarrolladores cortan esas conexiones con sustitutos llamados mocks y stubs: versiones falsas y sencillas de servicios externos que siempre dan la misma respuesta. Así, la prueba solo falla cuando la propia unidad tiene un problema.
Por ejemplo, imagine una tienda en línea que aplica un 10 % de descuento a toda compra superior a 100 €. Una prueba de la función de descuento podría introducir un pedido de 150 € y confirmar que el total resultante es de 135 €. Una segunda prueba podría probar exactamente 100 € para comprobar el límite de la regla. Una tercera podría enviar un importe negativo para asegurarse de que el código rechaza ese dato. Las tres pruebas terminan casi al instante, sin carrito, sin cliente y sin página de pago.
Sin embargo, el aislamiento tiene un límite: las pruebas unitarias no pueden decirle si las partes funcionan juntas. Por ejemplo, la función de descuento puede superar todas las pruebas mientras la página de pago sigue mostrando el precio completo.
¿Quién escribe las pruebas unitarias?
Los desarrolladores escriben y mantienen las pruebas unitarias en el mismo proyecto que el código del producto. Para ese trabajo, cada programador se apoya en un framework de pruebas, un conjunto de herramientas listo para escribir y lanzar comprobaciones. Algunos ejemplos populares son JUnit para Java, pytest para Python y Jest para JavaScript. Cada prueba unitaria se ejecuta primero en el ordenador del propio desarrollador. Después, la misma prueba se repite en el pipeline de CI (integración continua), un sistema automatizado que recompila y verifica el producto tras cada cambio en el código.
La rapidez de la respuesta es una de las razones por las que este trabajo corresponde a los desarrolladores. Una suite de pruebas bien construida, es decir, la colección completa de pruebas unitarias de un producto, termina en pocos minutos. Esa velocidad permite al programador corregir un error mientras todavía tiene el código fresco en la mente. La otra razón es que escribir esas pruebas implica leer y modificar el código del producto, que es el trabajo diario de los desarrolladores.
Aun así, los ingenieros de QA tienen un papel en las pruebas unitarias. En QAwerk revisamos las pruebas unitarias con los desarrolladores que las escriben y enumeramos las situaciones que ninguna prueba cubre todavía, por ejemplo un campo de formulario vacío, un pedido inusualmente grande o una conexión a internet perdida. Una vez que existen nuevas pruebas para esas carencias, una ejecución satisfactoria demuestra que el código también las gestiona.
¿Dónde se sitúan las pruebas unitarias en la pirámide de pruebas?
Muchos equipos de software organizan sus comprobaciones con la pirámide de pruebas, un diagrama que clasifica las pruebas por tamaño y velocidad. Las pruebas unitarias forman la base ancha porque son las más baratas de escribir y las más rápidas de ejecutar. Por eso, un producto puede tener fácilmente miles. Las pruebas de integración se sitúan en el medio y comprueban cómo funcionan juntas las distintas partes. En la estrecha cima, las pruebas de extremo a extremo siguen un recorrido completo del usuario, como registrarse y pagar una suscripción.
La forma de la pirámide refleja el coste. Una prueba unitaria se ejecuta en segundos, mientras que una compra automatizada en un navegador real puede tardar minutos. Además, esa ejecución más larga puede fallar por motivos ajenos al código, como una señal wifi débil. Por eso los equipos reservan las lentas ejecuciones en navegador para los recorridos completos del usuario y prueban las reglas y conexiones individuales en las capas inferiores.
La mayoría de los proyectos de software pasan por cuatro niveles de prueba estándar, en este orden: unitario, de integración, de sistema y de aceptación. Las pruebas de extremo a extremo suelen ejecutarse durante los dos últimos, una vez ensamblado todo el producto. Nuestra guía sobre las fases de las pruebas de software recorre los cuatro.
Pruebas unitarias vs pruebas de integración vs pruebas de extremo a extremo
Las pruebas unitarias, de integración y de extremo a extremo forman las tres capas de la pirámide. Por eso esos nombres son los que más aparecen en los planes de proyecto y en los informes de estado. Cada tipo detecta una clase de problema distinta. Esa diferencia importa al leer un informe: «todas las pruebas unitarias pasan» confirma que cada fragmento de código cubierto funciona por sí solo, pero ese resultado aún no demuestra que un cliente pueda completar una compra. La comparación siguiente muestra también por qué los equipos reducen al mínimo las comprobaciones de extremo a extremo y confían en las capas inferiores para la mayor parte del detalle.
Qué se comprueba
Una función o un pequeño fragmento de código
Una conexión entre partes o servicios
Un recorrido completo del usuario
Ejemplo típico
La regla de contraseñas rechaza cualquier valor de menos de 8 caracteres
Un pago correcto actualiza el estado del pedido
Un comprador busca en el catálogo, paga una chaqueta y recibe un correo de confirmación
Quién suele escribir las pruebas
Desarrolladores
Desarrolladores e ingenieros de QA
Ingenieros de automatización de QA
Cuánto tarda una prueba
Unos segundos como máximo
Hasta un minuto
Varios minutos
Qué indica un fallo
Exactamente qué función falló
Qué conexión falló
Que un recorrido está roto, pero rara vez dónde
Buenas prácticas de pruebas unitarias: cómo son las buenas pruebas
Las siguientes buenas prácticas de pruebas unitarias sirven también como preguntas para sus desarrolladores:
- ¿La suite completa termina en minutos? Los desarrolladores tienden a saltarse las ejecuciones lentas, y una comprobación que no se ejecuta no detecta nada.
- ¿Cada prueba se limita a un solo comportamiento? Así, un fallo nombra el problema con palabras sencillas, como «rechaza una dirección de correo vacía».
- ¿Las pruebas evitan servicios externos reales? Las comprobaciones que llaman a una base de datos o a un proveedor de pagos reales fallan cada vez que esos sistemas van lentos. Tras suficientes falsas alarmas, la gente empieza a ignorar los fallos por completo.
- ¿Se prueban los casos de error? Los errores graves suelen esconderse en el código que gestiona datos de entrada incorrectos. Una función que lee una fecha de nacimiento necesita pruebas para un campo vacío y un formato incorrecto, además del caso normal.
- ¿La cobertura se trata como guía o como objetivo? La cobertura de código es la proporción de un programa que las pruebas ejecutan realmente. Un porcentaje bajo señala zonas sin probar. Sin embargo, un porcentaje alto demuestra poco por sí solo, ya que una prueba puede ejecutar una línea de código sin comprobar el resultado.
- ¿La suite se ejecuta con cada cambio? El pipeline de CI debería lanzar las pruebas automáticamente e impedir que cualquier actualización que provoque un fallo llegue a la versión principal del producto.
- ¿Quién revisa las pruebas escritas por IA? Las herramientas de IA ya pueden escribir pruebas unitarias en segundos, lo que ahorra tiempo real. Aun así, cuando Meta estudió un generador de pruebas interno, los ingenieros aceptaron el 73 % de las pruebas propuestas y rechazaron el resto tras revisarlas, así que un programador o un especialista de QA debería aprobar cada prueba generada antes de que se incorpore a la suite.
¿Qué papel tiene QA junto a las pruebas unitarias?
Unas buenas pruebas unitarias cambian el enfoque del trabajo de un equipo de QA. Cuando la lógica básica ya está cubierta, los testers encuentran menos errores simples, como un total incorrecto o un formato de fecha roto. Así, los ingenieros de QA pueden concentrarse en los problemas que las pruebas unitarias no ven, que aparecen entre las partes del producto y ante usuarios reales:
- Cómo funcionan las partes juntas: las pruebas de integración comprueban las conexiones, por ejemplo si una reserva confirmada envía realmente un correo al cliente. En productos vinculados a proveedores externos y plataformas de socios, las pruebas de integración de sistemas cubren también esos vínculos.
- Si las funciones antiguas siguen funcionando: las pruebas de regresión vuelven a ejecutar comprobaciones anteriores tras cada actualización, porque un cambio en un sitio puede romper una funcionalidad en otro.
- Cómo se siente el producto al usarlo: las pruebas manuales realizadas por un especialista con experiencia detectan pantallas confusas y comportamientos extraños. Parte de ese trabajo son las pruebas exploratorias, una investigación libre del producto sin un guion preparado.
Junto con las pruebas unitarias, ese trabajo forma las pruebas de calidad del software, en las que cada tipo de comprobación detecta problemas que los demás pasan por alto. Nuestros ingenieros parten de las pruebas que sus desarrolladores ya han escrito y construyen encima una cobertura automatizada y manual. Así no se duplica ningún trabajo y nada se escapa.
¿Quiere encontrar los huecos que sus pruebas unitarias no cubren? Hable con nuestro equipo.
Preguntas frecuentes
¿Las pruebas unitarias son lo mismo que las pruebas de componentes?
Las pruebas unitarias y las pruebas de componentes suelen tratarse como lo mismo, pero el glosario del ISTQB, la referencia estándar de la terminología de QA, ahora da a cada término su propia definición. La pieza comprobable más pequeña de un programa, normalmente una sola función, cuenta como unidad. Un componente puede ser más grande, como un módulo de pagos formado por muchas piezas más pequeñas. Aun así, la prueba lo separa del resto del sistema.
¿QA escribe pruebas unitarias?
Las pruebas unitarias suelen ser trabajo de los desarrolladores, ya que viven dentro del código fuente del producto y se vuelven a ejecutar tras cada edición. Los ingenieros de QA contribuyen revisando las pruebas existentes en busca de casos que faltan y probando lo que las funciones individuales no pueden revelar, como un vínculo roto entre dos sistemas. En algunos proyectos, los especialistas en automatización con acceso al código también escriben estas pruebas cuando los desarrolladores van justos de tiempo.
¿Cuánta cobertura de pruebas unitarias es suficiente?
Ninguna cifra de cobertura sirve para todos los productos. Perseguir el 100 % significa hacer que cada línea de código se ejecute en al menos una prueba. Ese objetivo rara vez compensa, porque el esfuerzo se va en código trivial solo para mover la cifra. Un objetivo mejor para las pruebas unitarias es una cobertura casi completa de las áreas de alto riesgo, como pagos, precios, inicio de sesión y datos de clientes almacenados. Después, revisiones periódicas deberían confirmar qué verifica realmente cada prueba.
¿Puede la IA escribir pruebas unitarias?
Sí, la IA puede generar pruebas unitarias y resolver bien el trabajo repetitivo, como enumerar decenas de variaciones de entrada para una función. Su punto débil es la intención de negocio. Un modelo de IA lee el código existente al pie de la letra, así que, si hay un error, la prueba generada puede fijarlo como comportamiento esperado. Toda prueba escrita por IA necesita que una persona confirme que se ajusta a lo que quiere el negocio.
Mira cómo ayudamos a ChitChat a resolver más de 200 errores en 24 dispositivos reales antes de su primer lanzamiento en tienda
