{"id":19636,"date":"2026-10-03T07:12:00","date_gmt":"2026-10-03T05:12:00","guid":{"rendered":"https:\/\/martagonzalez.dev\/wp\/blog\/\/"},"modified":"2026-06-15T15:37:14","modified_gmt":"2026-06-15T13:37:14","slug":"como-escribir-tu-primer-test-unitario-en-javascript","status":"publish","type":"post","link":"https:\/\/martagonzalez.dev\/wp\/blog\/como-escribir-tu-primer-test-unitario-en-javascript\/","title":{"rendered":"C\u00f3mo escribir tu primer test unitario en JavaScript"},"content":{"rendered":"
<\/div>
<\/div><\/div>\n
\"\"<\/figure>\n\n\n\n

Aprender a escribir un test unitario en JavaScript puede parecer un paso muy t\u00e9cnico al principio, especialmente si vienes de centrarte en crear interfaces, resolver funcionalidades o entregar cambios r\u00e1pido. Sin embargo, cuanto antes incorporas el testing a tu forma de trabajar, antes empiezas a notar una diferencia importante: desarrollas con m\u00e1s seguridad, detectas errores antes y entiendes mejor c\u00f3mo deber\u00eda comportarse tu propio c\u00f3digo.<\/p>\n\n\n\n

Un test unitario no es una garant\u00eda absoluta de que una aplicaci\u00f3n nunca fallar\u00e1, pero s\u00ed es una herramienta muy \u00fatil para comprobar que una parte peque\u00f1a y concreta del c\u00f3digo hace exactamente lo que esperas. En lugar de abrir el navegador, probar manualmente varios casos y confiar en que todo sigue funcionando, puedes escribir una prueba automatizada que verifique ese comportamiento por ti.<\/p>\n\n\n\n

En este art\u00edculo vamos a ver c\u00f3mo escribir tu primer test unitario en JavaScript desde cero, con una explicaci\u00f3n clara, ejemplos sencillos y buenas pr\u00e1cticas para que no solo copies c\u00f3digo, sino que entiendas qu\u00e9 est\u00e1s haciendo. Si todav\u00eda est\u00e1s construyendo una base sobre testing, tambi\u00e9n puede ayudarte leer esta gu\u00eda sobre qu\u00e9 es el testing unitario y cu\u00e1ndo usarlo<\/a>, donde se explica el concepto desde una perspectiva m\u00e1s general.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Qu\u00e9 es un test unitario en JavaScript<\/h2>\n\n\n\n

Un test unitario es una prueba automatizada que verifica el comportamiento de una unidad peque\u00f1a de c\u00f3digo. Esa unidad puede ser una funci\u00f3n, un m\u00e9todo, una utilidad, una transformaci\u00f3n de datos o una pieza l\u00f3gica concreta de una aplicaci\u00f3n.<\/p>\n\n\n\n

Por ejemplo, si tienes una funci\u00f3n que suma dos n\u00fameros, un test unitario puede comprobar que al pasarle 2<\/code> y 3<\/code>, el resultado sea 5<\/code>. Parece algo demasiado simple, pero esa sencillez es precisamente una de las claves del testing unitario: comprobar piezas peque\u00f1as de forma aislada.<\/p>\n\n\n\n

function sumar(a, b) {\n  return a + b;\n}\n<\/code><\/pre>\n\n\n\n
Un test unitario para esa funci\u00f3n podr\u00eda expresar algo como:<\/p>\n\n\n\n
esperamos que sumar(2, 3) devuelva 5\n<\/code><\/pre>\n\n\n\n
La ventaja est\u00e1 en que esta comprobaci\u00f3n se puede ejecutar todas las veces que quieras. Si m\u00e1s adelante alguien modifica la funci\u00f3n y rompe su comportamiento, el test fallar\u00e1 y te avisar\u00e1.<\/p>\n\n\n\n
Diferencia entre probar manualmente y escribir tests<\/h3>\n\n\n\n
Cuando pruebas manualmente una funcionalidad, normalmente sigues una serie de pasos: abres la aplicaci\u00f3n, haces clic, introduces datos y observas el resultado. Este proceso es necesario en muchos casos, pero tambi\u00e9n tiene l\u00edmites. Puedes olvidarte de revisar un caso, repetir pruebas consume tiempo y es f\u00e1cil asumir que algo funciona solo porque funcion\u00f3 una vez.<\/p>\n\n\n\n
En cambio, las pruebas unitarias JavaScript permiten automatizar comprobaciones peque\u00f1as y repetibles. No sustituyen todo el trabajo de revisi\u00f3n, pero s\u00ed reducen la dependencia de la memoria y de la intuici\u00f3n.<\/p>\n\n\n\n
Probar manualmente responde a la pregunta: \u201c\u00bfparece que esto funciona ahora?\u201d<\/em>.
Un test unitario responde a la pregunta: \u201c\u00bfesta parte concreta del c\u00f3digo sigue comport\u00e1ndose como hab\u00edamos definido?\u201d<\/em>.<\/p>\n\n\n\n
Si quieres ampliar la visi\u00f3n general, puedes complementar esta lectura con el art\u00edculo sobre tipos de testing en aplicaciones web<\/a>, donde se explican las diferencias entre pruebas unitarias, de integraci\u00f3n, end to end y otros enfoques.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Por qu\u00e9 deber\u00edas aprender testing JavaScript desde el principio<\/h2>\n\n\n\n
Muchas personas empiezan a interesarse por el testing JavaScript cuando el proyecto ya ha crecido, cuando hay miedo a tocar ciertas partes del c\u00f3digo o cuando una correcci\u00f3n rompe otra funcionalidad sin querer. Aunque nunca es tarde para empezar, aprender testing desde el principio tiene varias ventajas.<\/p>\n\n\n\n
La primera es que te ayuda a escribir c\u00f3digo m\u00e1s claro. Para poder testear una funci\u00f3n, esa funci\u00f3n debe tener una responsabilidad concreta. Si una funci\u00f3n hace demasiadas cosas, tiene dependencias ocultas o mezcla l\u00f3gica con efectos secundarios, escribir un test se vuelve complicado. Por eso, el testing tambi\u00e9n act\u00faa como una se\u00f1al de dise\u00f1o.<\/p>\n\n\n\n
La segunda ventaja es que te da confianza al refactorizar. Refactorizar significa mejorar la estructura interna del c\u00f3digo sin cambiar su comportamiento externo. Si tienes tests que verifican ese comportamiento, puedes reorganizar el c\u00f3digo con menos miedo.<\/p>\n\n\n\n
La tercera ventaja es que mejora la comunicaci\u00f3n dentro de un equipo. Un test bien escrito funciona casi como documentaci\u00f3n ejecutable. Explica qu\u00e9 se espera de una funci\u00f3n y qu\u00e9 casos se consideran importantes.<\/p>\n\n\n\n
Cu\u00e1ndo tiene sentido escribir un test unitario<\/h3>\n\n\n\n
No hace falta testear absolutamente todo. Un error com\u00fan al empezar es pensar que cualquier l\u00ednea de c\u00f3digo debe tener una prueba asociada. En la pr\u00e1ctica, conviene priorizar aquellas partes donde un fallo puede tener impacto real.<\/p>\n\n\n\n
Tiene mucho sentido escribir tests unitarios para funciones que transforman datos, validaciones de formularios, c\u00e1lculos de precios, utilidades reutilizables, reglas de negocio o casos l\u00edmite que podr\u00edan romperse con facilidad.<\/p>\n\n\n\n
Por ejemplo, si tienes una funci\u00f3n que calcula el precio final de un producto con descuento, ah\u00ed un test unitario puede ahorrarte muchos problemas. Si el c\u00e1lculo falla, el impacto puede ser importante.<\/p>\n\n\n\n
Qu\u00e9 no suele ser ideal para un primer test unitario<\/h4>\n\n\n\n
Para empezar, no conviene elegir una parte demasiado compleja de la aplicaci\u00f3n. Si tu primer test intenta cubrir una pantalla completa, una llamada a una API, una interacci\u00f3n con el DOM y varios estados al mismo tiempo, es probable que termines frustrada.<\/p>\n\n\n\n
Para tu primer test unitario JavaScript, lo mejor es elegir una funci\u00f3n pura: una funci\u00f3n que recibe unos datos, devuelve un resultado y no depende de elementos externos. Este enfoque se relaciona directamente con la forma de trabajar explicada en la gu\u00eda sobre c\u00f3mo testear funciones puras en JavaScript<\/a>.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Preparar el entorno para escribir tu primer test<\/h2>\n\n\n\n
Para escribir tests en JavaScript necesitas un entorno de ejecuci\u00f3n y una herramienta de testing. En este art\u00edculo vamos a usar Jest, porque es una opci\u00f3n muy conocida, tiene una sintaxis accesible y permite empezar con pocos pasos.<\/p>\n\n\n\n
Tambi\u00e9n podr\u00edas usar Vitest, especialmente si trabajas con Vite, React o proyectos frontend modernos. La l\u00f3gica de los primeros tests es muy parecida: defines un caso, ejecutas una funci\u00f3n y compruebas el resultado esperado. Si tu proyecto ya usa Vite, te puede interesar esta gu\u00eda espec\u00edfica sobre Vitest para proyectos modernos con Vite<\/a>.<\/p>\n\n\n\n
Crear un proyecto b\u00e1sico<\/h3>\n\n\n\n
Primero, crea una carpeta para el ejemplo:<\/p>\n\n\n\n
mkdir primer-test-js\ncd primer-test-js\n<\/code><\/pre>\n\n\n\n
Despu\u00e9s inicializa un proyecto con npm:<\/p>\n\n\n\n
npm init -y\n<\/code><\/pre>\n\n\n\n
Esto generar\u00e1 un archivo package.json<\/code>, donde se guardar\u00e1 la configuraci\u00f3n b\u00e1sica del proyecto y los scripts que podr\u00e1s ejecutar desde la terminal.<\/p>\n\n\n\n
Ahora instala Jest como dependencia de desarrollo:<\/p>\n\n\n\n
npm install --save-dev jest\n<\/code><\/pre>\n\n\n\n
Una dependencia de desarrollo es una herramienta que necesitas para trabajar en el proyecto, pero que no forma parte necesariamente del c\u00f3digo final que se ejecutar\u00e1 en producci\u00f3n.<\/p>\n\n\n\n
Configurar el script de test<\/h3>\n\n\n\n
Abre el archivo package.json<\/code> y busca la secci\u00f3n \"scripts\"<\/code>. Puedes modificarla as\u00ed:<\/p>\n\n\n\n
{\n  \"scripts\": {\n    \"test\": \"jest\"\n  }\n}\n<\/code><\/pre>\n\n\n\n
Con esto podr\u00e1s ejecutar los tests usando:<\/p>\n\n\n\n
npm test\n<\/code><\/pre>\n\n\n\n
Este comando le dir\u00e1 a Jest que busque archivos de prueba en el proyecto y los ejecute.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Crear una funci\u00f3n sencilla para testear<\/h2>\n\n\n\n
Vamos a empezar con una funci\u00f3n muy simple. Crea un archivo llamado sumar.js<\/code>:<\/p>\n\n\n\n
function sumar(a, b) {\n  return a + b;\n}\n\nmodule.exports = sumar;\n<\/code><\/pre>\n\n\n\n
Esta funci\u00f3n recibe dos valores y devuelve la suma. Adem\u00e1s, usamos module.exports<\/code> para poder importarla desde el archivo de test.<\/p>\n\n\n\n
Aunque el ejemplo sea b\u00e1sico, tiene algo importante: la funci\u00f3n es predecible. Si le pasamos 2<\/code> y 3<\/code>, esperamos 5<\/code>. Si le pasamos -1<\/code> y 1<\/code>, esperamos 0<\/code>. Esta claridad facilita mucho el aprendizaje.<\/p>\n\n\n\n
Qu\u00e9 significa testear una funci\u00f3n<\/h3>\n\n\n\n
Testear una funci\u00f3n no consiste solo en comprobar que \u201cfunciona\u201d. Eso es demasiado general. Un buen test define un escenario concreto.<\/p>\n\n\n\n
Por ejemplo:<\/p>\n\n\n\n