DEV Community: Johan Garcia

Camino a CI/CD pruebas (Testing)

Johan Garcia — Fri, 10 Apr 2026 05:09:40 +0000

El stage de testing es, en la mayoría de pipelines, la etapa que sigue después de la compilación o build. En este punto, el sistema ya es ejecutable, pero aún no es confiable.

Aquí es donde entra el testing: no como un paso opcional, sino como el filtro que evita que errores, regresiones o comportamientos inesperados lleguen a producción.

En esta sección, se busca responder una pregunta clave:

¿Qué debería tener un pipeline a nivel de testing para considerarse realmente sólido?

Tipos de Testing

1. Testing Funcional

El testing funcional valida que el sistema haga lo que se espera que haga. Es decir, se enfoca en el comportamiento, no en cómo está implementado.

Unit Testing (Pruebas Unitarias)

Las pruebas unitarias validan las piezas más pequeñas del sistema: funciones, métodos o componentes individuales.

Su objetivo es detectar errores lo más temprano posible, antes de que escalen.

Qué cubren normalmente:

Lógica de negocio aislada
Validaciones
Transformaciones de datos
Casos borde

Aquí no importa el sistema completo, solo que esa unidad funcione correctamente.

Integration Testing (Pruebas de Integración)

Aquí se sube un nivel: ya no se prueba una pieza aislada, sino cómo interactúan varias partes del sistema.

El objetivo es validar que los componentes colaboren correctamente.

Qué suele incluir:

Componentes + servicios
Acceso a base de datos
APIs simuladas (MSW, mocks controlados)

Ejemplo conceptual:

Un componente llama a un servicio → el servicio consulta datos → el resultado se renderiza correctamente.

Si alguna de esas piezas falla en conjunto, el test lo detecta.

End-to-End Testing (E2E)

Las pruebas E2E validan el sistema completo desde la perspectiva del usuario.

Simulan flujos reales en un entorno lo más cercano posible a producción.

Ejemplo típico:

El usuario entra a la app
Hace login
Crea un registro
Lo visualiza en pantalla

Si todo eso funciona, el sistema cumple su propósito en ese flujo.

Smoke Testing

El smoke testing responde una única pregunta:

¿El sistema funciona lo suficiente como para seguir probándolo?

Se ejecuta justo después del build, y actúa como un primer filtro.

Si falla aquí, no tiene sentido continuar.

Ejemplo:

¿La app levanta?
¿El login responde?
¿una ruta principal carga?

No valida lógica profunda ni reglas complejas.

Solo verifica lo esencial.

Este test no valida:

expiración del token
roles
seguridad avanzada

Solo valida algo clave: “¿el login funciona?”, Si esto falla, todo lo demás deja de tener sentido.

Sanity Testing

El sanity testing es un chequeo rápido y enfocado después de un cambio puntual.

No busca validar todo el sistema, sino algo muy concreto:

¿Lo que se modificó sigue funcionando sin romper lo demás?

Se usa cuando:

Hay un bug fix
Se hace un refactor pequeño
Se ajusta una funcionalidad específica

Características:

Dirigido (no exploratorio)
Ligero (no exhaustivo)
Rápido (busca confianza inmediata)

Regression Testing

El regression testing protege el sistema a medida que evoluciona.

Cada cambio introduce riesgo, y este tipo de pruebas actúa como una red de seguridad.

Valida que:

Lo que funcionaba → siga funcionando
Los cambios → no generen efectos colaterales

No se enfoca en lo nuevo, sino en evitar que lo existente se rompa.

User Acceptance Testing (UAT)

Es la fase donde el sistema deja de evaluarse como “código que funciona” y pasa a validarse como “producto que resuelve un problema real”. Aquí ya no importa tanto si la lógica interna está bien implementada, sino si lo que se construyó realmente cumple con lo que el usuario o el negocio esperaba.

En otras palabras, es el momento en el que alguien del lado del negocio no necesariamente un desarrollador usa la aplicación en escenarios reales y responde una pregunta clave: ¿esto sirve para lo que se necesitaba?

A diferencia de otros tipos de testing:

No se centra en funciones aisladas.
No valida detalles técnicos.
No busca bugs “técnicos” principalmente.

Se enfoca en algo mucho más importante:

Validar que el sistema cumple con los requisitos funcionales desde la perspectiva del usuario final.

Ejemplo

Contexto: Un módulo de inventario.

Requisito de negocio:
“El usuario debe poder registrar un producto y verlo reflejado en el inventario.”

UAT:
Escenario:

El usuario crea un producto: Nombre: “Laptop” Cantidad: 5
Guarda el registro
Va al listado de inventario

Resultado esperado:

El producto aparece
La cantidad es correcta

No hay inconsistencias

Si eso pasa, el sistema cumple el requisito, aunque internamente pueda tener mejoras técnicas pendientes.

Tipos de UAT que suelen aparecer
Aunque muchas veces se agrupan como uno solo, en la práctica se ven variantes:

Alpha Testing → interno (equipo del producto)
Beta Testing → usuarios reales
Business UAT → validación contra requisitos del negocio
Operational UAT → validación en condiciones reales (ambiente, datos, etc.)

Consideraciones

El UAT no lo hace el desarrollador

Normalmente lo ejecutan:

Stakeholders
QA con enfoque de negocio
Cliente final

Porque lo que se valida no es el código, sino la utilidad real del sistema.

Su finalidad es

Ejecutarse en entornos de staging
Ser parcialmente manual (aunque puede automatizarse con criterios de aceptación)
Actuar como último gate antes de producción

Contract Testing

Este tipo de testing se vuelve crítico en arquitecturas distribuidas.

Valida que dos sistemas que se comunican (por ejemplo, frontend y backend) respeten un contrato.

Ese contrato define:

Request
Response
Tipos de datos
Campos obligatorios

Problema típico que resuelve:

El backend funciona, sus tests pasan… pero el frontend se rompe.
El contract testing evita ese tipo de desalineaciones.

El backend funciona
Los tests del backend pasan
Pero el frontend se rompe

Aquí es donde el Contract Testing evita el desastre.

Tipos de Contract Testing
Consumer-Driven Contract Testing (el más usado)
El consumidor (frontend) define lo que necesita.

Ejemplo

Provider Verification
El backend valida que cumple ese contrato.

Ejemplo

2. Testing No Funcional
Aquí no se valida qué hace el sistema, sino cómo se comporta.

Performance Testing
Se centra en evaluar cómo se comporta una aplicación bajo distintas condiciones de carga, no desde la lógica funcional, sino desde atributos como tiempo de respuesta, throughput, uso de recursos y estabilidad. En términos prácticos, lo que se busca es responder preguntas como: ¿cuántos usuarios simultáneos puede soportar el sistema?, ¿qué tan rápido responde bajo presión?, ¿en qué punto comienza a degradarse? Este tipo de pruebas es clave en sistemas reales porque muchos fallos no aparecen en desarrollo, sino cuando el sistema enfrenta tráfico real. Dentro de este enfoque se incluyen variantes como load testing, stress testing y spike testing, cada una orientada a distintos patrones de carga.

Ejemplo

El el ejemplo anterior se simulan 50 usuarios concurrentes durante 30 segundos haciendo peticiones al mismo endpoint. Si el sistema responde rápido y sin errores, el comportamiento es aceptable. Si el tiempo de respuesta aumenta significativamente o aparecen errores (timeouts, 500), entonces ya se está evidenciando un problema de rendimiento.

Security Testing
Aunque forma parte del testing, muchas veces se maneja como un stage independiente.

Incluye:

SAST - Static Application Security Testing (análisis estático)
DAST - Dynamic Application Security Testing (análisis dinámico)
SCA - Software Composition Analysis
Secrets Detection
Container Security
IaC, API, y Compliance
Security Headers
Dependency Scanning

Mutation Testing (Pruebas de Mutación)
El mutation testing pregunta: "Si introduzco un pequeño bug en mi código, ¿mis pruebas realmente lo detectarán?" Esto revela la diferencia crítica entre cobertura de pruebas y efectividad de pruebas.

El resultado se mide con el mutation score.

Ejemplo

Herramientas

Testing Unitario e Integración

Jest (JavaScript/TypeScript)
Pytest (Python):
JUnit (Java)
NUnit (C#/.NET)

Testing E2E y UI

Selenium: Arquitectura empresarial de Selenium Python con Pytest, Allure y patrones de diseño GitHub
Cypress
Playwright
Puppeteer

Contract Testing

Pact: Flujo típico con Pact:
- El frontend define el contrato
- Se guarda como archivo (.json)
- El backend ejecuta tests contra ese contrato Si algo no coincide → falla el pipeline

Testing Performance

Locust (Python)
K6 (JavaScript/TS): Ofrece integración nativa con CI/CD y la nube.
Gatling (Java/Kotlin/JS/Scala)
Apache JMeter Java/GUI): Ideal para equipos QA tradicionales y empresas, siendo opensource.
Atillery (Node.js/YAML)
Vegeta (Go)

Alternativas en la nube para Testing performance

BlazeMeter: Permite ejecutar scripts de JMeter, k6, Locust y Gatling en la nube
LoadNinja: Se enfoca en pruebas con navegadores reales en lugar de simular protocolos, lo que da métricas de experiencia de usuario más precisas. No requiere programación
Azure Load Testing: Un servicio gestionado por Microsoft que permite subir scripts de JMeter y ofrece integraciones profundas con el ecosistema de Azure.
OctoPerf: Diseñado específicamente para usuarios de JMeter que quieren una interfaz web moderna

Testing Mutation

PIT (PITest) para Java con escalabilidad empresarial.
Stryker Mutator con soporte multi-lenguaje (JavaScript, TypeScript, C#, Scala).
MutPy para Python.
Infection para PHP.

Un buen stage de testing no se define por la cantidad de herramientas o tests, sino por su capacidad de generar confianza.

Al final, todo se resume en esto:

Detectar errores lo antes posible, con el menor costo posible, y antes de que impacten al usuario.

Si el pipeline logra eso, entonces está bien diseñado.

Como potenciar tu VS Code con Continue.dev Cline

Johan Garcia — Fri, 25 Apr 2025 05:36:10 +0000

Hoy en día, vemos la inteligencia artificial (IA) en todas partes, y no es de extrañar que, en el mundo del desarrollo de software, se estén explorando una gran variedad de usos. Un claro ejemplo son los editores de código con integración de IA, como Cursor.ai, Windsurf o el más reciente Firebase Studio. Estas herramientas ofrecen funcionalidades avanzadas, como autocompletado inteligente y generación o edición de código a partir de prompts.

Hace unas semanas estuve probando tanto Cursor como Windsurf en algunos de mis proyectos personales, y, sinceramente, es increíble lo que se puede lograr cuando sabes bien lo que estás haciendo. Investigando un poco más, encontré una forma de darle “músculo” a Visual Studio Code —recordemos que Cursor y Windsurf están basados en VS Code—, ya que este, por defecto, no incluye muchas de las características que sí ofrecen estas versiones modificadas de pago.

La solución: integrar Continue.dev y Cline, dos extensiones poderosas y open source para VS Code, que transforman tu editor en un verdadero IDE con esteroides. En este artículo te voy a mostrar cómo configurarlas paso a paso, qué modelos puedes usar, sus limitaciones y por qué esta combinación puede convertirse en tu nuevo entorno favorito para programar con IA.

REQUISITOS PREVIOS

Tener Visual Studio Code instalado.
Contar con una cuenta gratuita en Groq y OpenRouter.
En el apartado de extensiones de VS Code, buscar la extensión Continue y asegurarte de seleccionar al desarrollador: Continue.

Al instalarla, se creará una carpeta llamada .continue/ en la raíz de tu espacio de trabajo, que suele ubicarse en C:\Users\user. (Es importante tener presente este punto)

Luego, en el mismo apartado de extensiones de VS Code, buscar la extensión Cline y seleccionar al desarrollador: Cline.bot.

Existen otros proveedores de modelos de IA, como Together AI, pero, al parecer, este no ofrece modelos open source.

¿Cómo funciona Continue.dev?
Continue.dev actúa como un asistente inteligente dentro de Visual Studio Code. Sus principales funciones incluyen:

Leer y analizar tu código fuente.
Completar funciones o bloques de código completos.
Editar fragmentos mediante prompts.
Responder preguntas técnicas o sugerir mejoras.
Leer el contexto del proyecto (archivos, terminal, errores, etc.).

Está especialmente orientado a desarrolladores que desean integrar modelos de lenguaje (LLMs) para mejorar su flujo de trabajo, particularmente en proyectos de tamaño mediano a grande.

¿Cómo funciona Cline?
Cline es un complemento para VS Code que permite crear un agente personalizado impulsado por LLMs, capaz de ejecutar comandos, navegar entre archivos y mantener conversaciones contextuales. A diferencia de Continue.dev —que se enfoca principalmente en la edición y el completado de código—, Cline está orientado a establecer un flujo de trabajo interactivo bajo un enfoque agente-usuario.

Con Cline puedes:

Chatear con un agente inteligente directamente desde el editor.
Ejecutar tareas específicas mediante comandos configurables.
Definir skills (habilidades) que combinan instrucciones con ejecución de código.
Personalizar completamente el comportamiento del agente mediante archivos YAML.

Está pensado para usuarios avanzados que buscan automatizar flujos repetitivos o construir asistentes que no solo respondan con texto, sino que también ejecuten acciones dentro del entorno de desarrollo.

Archivo config.yaml: explicación completa
El archivo .continue/config.yaml es el núcleo de la configuración de Continue.dev. A través de este archivo puedes definir:

Los modelos a utilizar: como Groq, OpenRouter u otros compatibles con Continue.
El comportamiento de cada modelo: incluyendo roles, mensajes del sistema, temperatura, y otras configuraciones específicas que controlan cómo responde el modelo.
El contexto que tendrá el agente: qué archivos, errores o entradas del terminal podrá leer para generar respuestas más precisas y útiles.

Ejemplo con Groq y OpenRouter:

Explicación de propiedades clave del archivo config.yaml

name: Nombre visible del asistente o modelo en la interfaz de Continue.
provider: Proveedor del modelo, como groq, openrouter, entre otros.
model: Identificador del modelo específico ofrecido por el proveedor.
apiKey: Clave de autenticación necesaria para conectarse con el proveedor.
roles: Define las funciones que puede desempeñar el modelo, como chat, autocomplete o edit.
systemMessage: Mensaje base que establece el comportamiento general del asistente (por ejemplo, su tono, propósito o enfoque).
context: Determina qué fuentes de información se usarán como contexto, como archivos de código, terminal, errores, etc.
apiBase: Dirección base para la conexión con la API, necesaria en algunos proveedores como Groq.
Limitaciones de Continue.dev
No todos los modelos soportan todas las funciones. Por ejemplo, algunos modelos no permiten funciones como edición (edit) o autocompletado (autocomplete). En estos casos, Continue mostrará una alerta indicando qué modelo y qué rol no son compatibles.
No permite entrenamiento ni afinado de modelos desde la interfaz.
Algunas integraciones pueden requerir configuración manual (por ejemplo, definir rutas o parámetros específicos).
Depende en gran medida del modelo seleccionado: si el modelo es limitado, la calidad de las respuestas también lo será.

Limitaciones de los modelos: Groq vs OpenRouter
Groq

Totalmente gratuito y sin necesidad de tarjeta de crédito.
Modelos disponibles: LLaMA 3, Mixtral, Gemma.
Ofrece alta velocidad de respuesta, ideal para flujos interactivos.
Limitado a los modelos disponibles en su plataforma.
No permite configuración avanzada, como ajuste fino (fine-tuning).

OpenRouter

Funciona como un proxy que da acceso a múltiples modelos (Claude, Mistral, GPT, entre otros).
Algunos modelos ofrecen un uso gratuito limitado, mientras que otros requieren pago por uso.
Dispone de una versión gratuita diaria, aunque esta puede agotarse rápidamente si hay alta demanda.
Mayor flexibilidad de modelos, pero con una experiencia menos homogénea según el proveedor seleccionado.

Cuando accedemos a Continue.dev dentro de Visual Studio Code, inicialmente solo contaremos con un asistente por defecto llamado "My First Assistant". Este asistente viene preconfigurado y es completamente funcional desde el primer momento.
Además, desde el sitio web de Continue.dev, es posible seleccionar otros modelos disponibles con uso limitado gratuito, sin necesidad de configurarlos manualmente. Sin embargo, para un control total y acceso a modelos más potentes o personalizados, lo ideal es editar el archivo config.yaml como vimos anteriormente.

En nuestro caso, crearemos un agente personalizado de manera local, el cual dependerá directamente de la configuración definida en nuestro archivo config.yaml (como se mostró en la imagen anterior).

Este archivo será la clave para conectar con proveedores como Groq u OpenRouter, permitiéndonos aprovechar modelos avanzados de lenguaje de forma gratuita o bajo demanda, según el proveedor elegido.

Una vez que hayamos seleccionado y configurado los modelos que vamos a utilizar dentro de Continue.dev, deberíamos tener una vista similar a la que se muestra en la imagen superior.

Con esta configuración, Continue.dev ya estará funcionando correctamente, y solo nos queda comenzar a probar sus funcionalidades: autocompletado, chat o edición, siempre y cuando el modelo seleccionado lo permita.

Ahora continuaremos con Cline. Utilizar esta extensión es mucho más sencillo, siempre y cuando hayamos creado correctamente nuestras API keys en Groq, OpenRouter u otro proveedor de modelos.

Para agregar un modelo en Cline, simplemente seleccionamos la opción "Use your own API key", y desde ahí podemos conectar el modelo que deseamos utilizar con la extensión.

Si seleccionamos la opción "Get started for free", obtendremos acceso al modelo Claude 3.7 con ciertas limitaciones. Este acceso forma parte del free trial que ofrece Cline, el cual es ideal para hacer pruebas rápidas y conocer el funcionamiento de la herramienta.

Una vez que se agote el periodo gratuito, podemos continuar usando Cline integrando un proveedor externo, como Groq o OpenRouter, utilizando nuestra propia API key.

Recomiendo usar OpenRouter como proveedor dentro de Cline, ya que ofrece una amplia gama de modelos disponibles, como Qwen 2.5, LLaMA 3 o Gemini 2.5 Flash. Es importante tener en cuenta que la disponibilidad de estos modelos puede variar dependiendo del momento en que realices la implementación dentro de VS Code.

Por lo tanto, es recomendable verificar qué modelos están accesibles al momento de configurar el agente para asegurarse de elegir el más adecuado según las necesidades del proyecto.

Es importante tener en cuenta que, dado que estamos utilizando modelos opensource, la principal limitación es el tiempo de respuesta o los timeouts, especialmente debido al alto volumen de uso por parte de la comunidad.

Cline está diseñado específicamente para realizar cambios en tu código, lo que lo convierte en un asistente AI. Ambas extensiones, Continue.dev y Cline, pueden ser particularmente útiles en situaciones donde no tengamos acceso a internet y estemos trabajando con un modelo alojado localmente en nuestra PC.

Ahora bien, las letras pequeñas de usar un modelo local son las siguientes: deberás seleccionar un modelo que se ajuste a las especificaciones de tu computadora. Es crucial tener en cuenta los recursos de tu equipo (memoria, procesador, etc.) para evitar problemas de rendimiento.

Cuando trabajamos con un modelo local, podemos integrarlo tanto a Continue.dev como a Cline, lo que nos permite aprovechar las ventajas de ambas herramientas incluso sin conexión a internet.

Internacionalización en Aplicaciones React con i18next

Johan Garcia — Sat, 18 Jan 2025 22:53:57 +0000

Cada dia el mundo esta conectado, ofrecer contenido accesible en múltiples idiomas se ha convertido en una necesidad fundamental para aplicaciones modernas. En este artículo, abordaremos cómo implementar internacionalización en aplicaciones React utilizando i18next, una biblioteca flexible y poderosa para la gestión de traducciones.

¿Qué es la internacionalización de aplicaciones web?

Con la internacionalización (i18n) damos la capacidad a nuestras aplicaciones de ser adaptables a diferentes idiomas y regiones sin la necesidad de realizar cambios en su código fuente.

Esto incluye la traducción de textos, la adaptación de formatos de fecha, moneda, números y cualquier otro aspecto que varíe según la localización cultural de los usuarios.

¿Qué es i18next y por qué utilizarlo?

i18next es una solución popular de internacionalización que simplifica la gestión de traducciones en aplicaciones web, móviles y de escritorio. Ofrece soporte para:

Carga dinámica de idiomas.
Interpolación de variables en textos.
Gestor de recursos centralizado para traducciones.
Cambio de idioma en tiempo real.

Existen otras opciones a i18next, como lo son react-intl, LinguiJS, Polyglot.js, MessageFormat.js y Globalize, pero nos centraremos en i18next, ya que es una librería muy popular, cuenta con un buen número de descargas semanales en npm.js y destaca por su simplicidad a la hora de ser configurada en una aplicación de React.js.

A lo largo de este artículo, exploraremos cómo configurar y utilizar i18next en una aplicación React paso a paso.

Instalación y configuración

Comenzaremos instalando i18next junto con su paquete adaptador para React:

Una vez instalados los paquetes necesarios para la configuración de i18next, configuraremos la instancia principal de i18next en un archivo dedicado, por ejemplo, i18n.js.

Ahora crearemos los archivos que van a contener nuestras traducciones (es.json y en.json). Para ello, crearemos una carpeta en la raíz de nuestro proyecto React.js llamada locale.

es.JSON

en.JSON

Configurar el proveedor global

Para que las traducciones sean accesibles en toda la aplicación, envolveremos el componente principal con el proveedor I18nextProvider. Este paso se realiza en el archivo principal, como index.jsx.

Con esta configuración, todas las traducciones estarán disponibles en los componentes React.

Uso en componentes

Para traducir textos en los componentes, utilizaremos el hook useTranslation que proporciona react-i18next.

En este ejemplo, t es la función que busca las traducciones en el idioma actual.

Cambiar de idioma

Podemos implementar una funcionalidad para cambiar el idioma de la aplicación en tiempo real utilizando el método changeLanguage de la instancia de i18next:

Con esto, los usuarios podrán alternar entre idiomas sin recargar la aplicación.

Conclusión

En este artículo, hemos explorado los fundamentos para implementar internacionalización con i18next en una aplicación React. Hemos configurado el entorno para que funcione con I18nextProvider, pero existen enfoques diferentes, como Context API o HOC (Higher-Order Component). Si desean explorar estos acercamientos, pueden consultarlos en la documentación de react-i18next.

Rutas relativas y absolutas en programación

Johan Garcia — Mon, 13 Jan 2025 22:36:45 +0000

Una ruta es el método mediante el cual podemos referenciar un recurso o directorio en un sistema de archivos dentro de un sistema operativo. Teniendo esto claro, ¿por qué es importante conocer más sobre las rutas? Porque estas te ayudan a evitar errores y a referenciar de forma exacta los recursos o directorios necesarios para ser utilizados en nuestras aplicaciones.

Al saber indicar la localización exacta de un archivo o directorio mediante una cadena de caracteres, podemos trabajar de manera más eficiente y precisa.

Árbol de directorios

Antes de continuar, es importante definir un término clave para entender las rutas absolutas y relativas: el árbol de directorios. Este concepto representa una estructura jerárquica de directorios y archivos en un sistema operativo. Es un enfoque común cuando trabajamos directamente con sistemas de archivos, exploradores de carpetas o comandos de terminal, y es independiente de una aplicación específica.

Concepto del Árbol de Rutas
Un sistema de archivos está organizado en una estructura de árbol, donde:

Cada nodo es un directorio o un archivo.
El nodo raíz (/ en sistemas basados en UNIX o una unidad como C:\ en Windows) es el punto de inicio.
Cada rama conecta un directorio con sus subdirectorios o archivos.
Cada archivo o directorio tiene una ruta única que describe su posición en el árbol.

Estructura Jerárquica del Árbol
La estructura típica de un árbol de rutas en un sistema operativo puede representarse como:

Dentro de este árbol de directorios se encuentran las rutas absolutas y relativas, que es lo que veremos a continuación.

Rutas Absolutas:

Comienzan desde el directorio raíz (/ en sistemas basados en UNIX o C:\ en Windows).
Proporcionan la localización completa del archivo o directorio en el sistema.

Ejemplos:

En UNIX: /home/user/documents/file1.txt
En Windows: C:\Users\User\Documents\file1.txt

Rutas Relativas:

Se definen en relación con el directorio actual.
Ejemplo: Si estás en /home/user, la ruta relativa a file1.txt sería documents/file1.txt.

Rutas

Existen dos formas de expresar una ruta, su forma relativa y su forma absoluta que cumplen funciones distintas, en su mayoria las rutas.

Rutas Relativas
Una ruta relativa indica la ubicación de un archivo o recurso en relación con el directorio actual, o lo que sería lo mismo, la posición en la que nos encontramos dentro del sistema operativo (o el contexto actual). Estas rutas son más flexibles y se utilizan para acceder a archivos más cercanos o relacionados con la misma jerarquía de directorios en la que estamos trabajando.

Referenciación
Utilizaremos . para referenciar el directorio actual. Es útil para referirse a archivos o subdirectorios dentro del mismo directorio donde estás ubicado.

Utilizaremos .. para referenciar al directorio padre. Representa el directorio inmediatamente superior al actual.

Ejemplos

../file.txt se refiere a file.txt en el directorio padre.
../../anotherfile.txt retrocede dos niveles en la jerarquía y busca el archivo.

Tomaremos este directorio como ejemplo para explicar el uso de rutas relativas.

Supongamos que estamos trabajando dentro de Header.js y queremos utilizar las funcionalidades que se encuentran en helpers.js. Haríamos referencia de la siguiente forma:

Las ventajas de utilizar las rutas relativas son que no requieren un conocimiento completo de la estructura global del árbol de directorios.

Una desventaja sería utilizarlas en proyectos grandes, donde puede ser difícil mantener rutas que son especialmente largas, como (../../../).

Rutas Absolutas
Una ruta absoluta indica o señala la ubicación completa de un archivo, recurso o directorio desde la raíz del sistema de archivos. Estas rutas son independientes del directorio actual, más claras y explícitas sobre la ubicación del recurso. Además, pueden ser configuradas en algunos entornos, como TypeScript o Webpack.

Ejemplo
Si no estuviéramos trabajando con TypeScript o Webpack, haríamos uso de la raíz de nuestro árbol de archivos para ubicarnos en el recurso que necesitáramos (por ejemplo: C:\usuarios\usuario1\project\src\utils\helpers).

Sin embargo, en este caso estaremos utilizando TypeScript y haremos uso de baseUrl en tsconfig.json para configurar una URL base desde la cual podemos partir al utilizar rutas absolutas dentro de nuestro proyecto.

Ahora continuaremos con la configuración de nuestro tsconfig.json.

Con esta configuración dentro de TypeScript y tsconfig.json, podremos utilizar los alias en nuestras rutas absolutas sin necesidad de referenciar todo el árbol de rutas existente (C:\usuarios\usuario1\project\src\utils\helpers), lo que evitará definir rutas extensas y difíciles de mantener, o el uso de rutas relativas.

Conclusión
Es esencial que comprendamos el árbol de directorios y las diferencias entre las rutas relativas y absolutas, ya que este conocimiento facilitará enormemente la navegación y gestión de archivos en cualquier sistema operativo o entorno de desarrollo. Las rutas absolutas les ofrecen una referencia precisa y clara a archivos y directorios, lo que asegura que siempre puedan acceder a ellos sin depender del directorio en el que se encuentren. Por otro lado, las rutas relativas son ideales para trabajar dentro del mismo contexto o proyecto, proporcionando flexibilidad y simplicidad.

Saber cuándo y cómo utilizar cada tipo de ruta no solo mejora la organización de sus proyectos, sino que también optimiza la mantenibilidad y reduce los errores relacionados con la ubicación de recursos. En proyectos grandes, las rutas absolutas y los alias bien configurados pueden simplificar las referencias y hacer que el código sea más limpio y fácil de comprender.

Entender estos conceptos es crucial para mejorar la eficiencia y precisión al trabajar con archivos y al desarrollar aplicaciones, garantizando un flujo de trabajo más ágil y un código más robusto.

Si el proyecto es pequeño o no quieres modificar configuraciones, usa rutas relativas.
Si trabajas en un proyecto grande o quieres mejorar la claridad del código, configura rutas absolutas.