DEV Community

Vinicio Jiménez
Vinicio Jiménez

Posted on

Pruebas Automatizadas: utPLSQL para el Backend

🇺🇸 Read in English: Click here for the English version

🚀 Actualización: ¡Nos hemos mudado a nuestro dominio personalizado!
Disfruta de una mejor experiencia en
insightsapex.vinnyum.tech.

Domina las pruebas automatizadas en Oracle APEX para mejorar rendimiento y mantenibilidad

"El testing no es solo una fase; es una parte esencial de la arquitectura."

¿Alguna vez has sentido ese vacío en el estómago al desplegar un hotfix crítico
un viernes por la tarde? Esa ansiedad no son solo nervios, es una señal de
advertencia de una arquitectura frágil.

El error común en el desarrollo de software es creer que las pruebas
automatizadas son meramente una fase opcional para atrapar bugs antes del
despliegue. ¿La realidad? En un mundo cada vez más dependiente de sistemas
complejos, las pruebas automatizadas son fundamentales para la arquitectura de
la aplicación. Sin ellas, arriesgas introducir una deuda técnica inmanejable
que puede paralizar la escalabilidad y mantenibilidad de tu aplicación.

En este APEX Insight, exploraremos cómo utPLSQL habilita pruebas automatizadas
robustas para tu backend en Oracle APEX, permitiendo que tus aplicaciones
escalen y se adapten sin problemas mientras mantienen altos estándares de
rendimiento y calidad. Para una visión más amplia sobre arquitectura backend,
mira nuestros insights sobre
Buenas Prácticas PL/SQL.


El Desafío Arquitectónico

Las pruebas automatizadas en Oracle APEX presentan desafíos únicos:

  • Complejidad del PL/SQL: A diferencia del código de aplicación tradicional, la lógica PL/SQL a menudo está fuertemente acoplada con el esquema de la base de datos, dificultando su aislamiento para pruebas.
  • Frameworks de Prueba Limitados: Muchos desarrolladores desconocen las capacidades de utPLSQL, llevando a una subutilización de sus características para pruebas efectivas.
  • Resistencia Cultural: Los equipos pueden estar acostumbrados a procesos de prueba manuales, y cambiar a pruebas automatizadas requiere un cambio de mentalidad.

Estos desafíos pueden llevar a una aplicación frágil donde nuevos cambios
introducen comportamientos inesperados, aumentando el riesgo de tiempo de
inactividad y pérdida de confianza del usuario.


Modelos Mentales

Para implementar exitosamente pruebas automatizadas con utPLSQL, considera
estos modelos mentales:

  • Desarrollo Guiado por Pruebas (TDD): Adopta principios TDD donde las pruebas se escriben antes que el código. Esto lleva a un diseño que acomoda naturalmente las pruebas.
  • Separación de Responsabilidades: Diseña tus paquetes PL/SQL con límites claros para facilitar las pruebas. Cada paquete debe tener una responsabilidad única.
  • Integración Continua: Implementa un pipeline de CI/CD que ejecute tus pruebas automáticamente, asegurando que cada cambio sea validado contra tu suite de pruebas.
  flowchart LR
      A[Commit Código] --> B[Pipeline CI Activado]
      B --> C{Ejecutar utPLSQL}
      C -- Pasa --> D[Desplegar a QA]
      C -- Falla --> E[Notificar Desarrollador]
Enter fullscreen mode Exit fullscreen mode

📏 Regla de Oro: "Si no está probado, está roto."


Patrones Estratégicos

Para aprovechar exitosamente utPLSQL para pruebas automatizadas, sigue estos
patrones estratégicos:

  1. Estructura de Paquetes: Organiza tu código PL/SQL en paquetes. Cada
    paquete debe encapsular funcionalidad relacionada, lo que ayuda a aislar las
    pruebas.

  2. Utilización de utPLSQL: Usa las características de utPLSQL para definir
    pruebas para tu código PL/SQL. Esto incluye:

    • Aserciones para validar resultados
    • Procesos de configuración (setup) y limpieza (teardown) para entornos de prueba
  3. Suites de Prueba: Agrupa pruebas relacionadas en suites para ejecutarlas
    colectivamente, facilitando la gestión y reporte de resultados de pruebas.

A continuación, una vista de alto nivel de cómo se puede estructurar esto:

graph TD;
    A[Lógica de Aplicación] --> B[Paquetes PL/SQL]
    B --> C[Pruebas utPLSQL]
    C --> D[Resultados de Prueba]
    D --> E[Ciclo de Retroalimentación]
Enter fullscreen mode Exit fullscreen mode

Implementación Técnica

Aquí te mostramos cómo implementar utPLSQL en tu backend de Oracle APEX:

Código MALO: Enfoque Ingenuo

CREATE OR REPLACE PROCEDURE update_user (
    p_user_id IN NUMBER,
    p_username IN VARCHAR2
) IS
BEGIN
    UPDATE users SET username = p_username WHERE id = p_user_id;
END;
Enter fullscreen mode Exit fullscreen mode

Esto carece de cualquier forma de prueba, manejo de errores o validación.

Código BUENO: Usando utPLSQL

CREATE OR REPLACE PACKAGE user_management AS
    PROCEDURE update_user (p_user_id IN NUMBER, p_username IN VARCHAR2);
END user_management;
/

CREATE OR REPLACE PACKAGE BODY user_management AS
    PROCEDURE update_user (p_user_id IN NUMBER, p_username IN VARCHAR2) IS
    BEGIN
        -- Asegurar que el usuario existe antes de actualizar
        IF NOT user_exists(p_user_id) THEN
            RAISE_APPLICATION_ERROR(-20001, 'El usuario no existe.');
        END IF;

        UPDATE users SET username = p_username WHERE id = p_user_id;
    END update_user;
END user_management;
Enter fullscreen mode Exit fullscreen mode

Escribiendo la Prueba utPLSQL

CREATE OR REPLACE PACKAGE TEST_user_management AS
    --%suite(Pruebas de Gestión de Usuarios)

    --%test(Actualizar Usuario - Valido)
    PROCEDURE test_update_user_valid;

    --%test(Actualizar Usuario - ID Invalido lanza error)
    --%throws(-20001)
    PROCEDURE test_update_user_invalid;
END TEST_user_management;
/

CREATE OR REPLACE PACKAGE BODY TEST_user_management AS
    PROCEDURE test_update_user_valid IS
        l_actual VARCHAR2(50);
    BEGIN
        -- Actuar
        user_management.update_user(1, 'nuevo_usuario');

        -- Afirmar (Usando helper para obtener estado)
        SELECT username INTO l_actual FROM users WHERE id = 1;
        ut.expect(l_actual).to_equal('nuevo_usuario');
    END test_update_user_valid;

    PROCEDURE test_update_user_invalid IS
    BEGIN
        -- Actuar (Se espera excepción por anotación)
        user_management.update_user(999, 'nuevo_usuario');
    END test_update_user_invalid;
END TEST_user_management;
Enter fullscreen mode Exit fullscreen mode

💡 Cómo funciona: ¿Notas las anotaciones --%suite y --%test? Estos
comentarios mágicos le dicen al framework utPLSQL exactamente qué ejecutar,
eliminando la necesidad de archivos de configuración complejos.

📝 Nota: ¡Inténtalo tú mismo!
Puedes clonar un ejemplo funcional completo con estas pruebas en nuestro
Repositorio de Demos.


Errores Comunes

Incluso con una estrategia sólida, hay trampas que pueden descarrilar tus
esfuerzos de prueba:

  • Ignorar Dependencias: Las pruebas no deben depender de estados reales de la base de datos u otros sistemas externos. Usa mocks donde sea necesario.
  • Sobrecomplicar Pruebas: Mantén tus pruebas simples y enfocadas. Cada prueba debe evaluar un único comportamiento para evitar confusión.
  • Descuidar el Mantenimiento: A medida que tu aplicación evoluciona, también deberían hacerlo tus pruebas. Revisa y actualiza regularmente tu suite de pruebas para reflejar la lógica de negocio actual.

Consejo de Consultor: "Integra regularmente las pruebas en tu pipeline de
despliegue para detectar problemas temprano."


Lista de Verificación del Consultor

Antes de desplegar tu estrategia de pruebas automatizadas, valida con estas
preguntas contundentes. Entornos estables crean pruebas estables. Asegura que la
configuración de tu app no sabotee la automatización:

  • ¿Está deshabilitado Rejoin Sessions?
  • ¿Están todas las protecciones de Items configuradas en Restricted?
  • ¿Usamos un esquema de parseo dedicado?
  • ¿Se ejecutan las pruebas automáticamente en cada build?
  • ¿Existe una propiedad clara de las pruebas dentro del equipo?

Conclusión

Las pruebas automatizadas usando utPLSQL no son solo una mejora; son una
necesidad para construir aplicaciones Oracle APEX escalables y mantenibles. Al
adoptar los principios discutidos, puedes pasar de un enfoque reactivo a uno
proactivo en la gestión de la calidad del software.

Recuerda, el objetivo no es meramente escribir pruebas, sino integrar el
testing en tu ADN arquitectónico. Esto finalmente conducirá a una mayor
velocidad del equipo, reducción de deuda técnica y una aplicación más robusta.

¿Cuál es la razón número uno por la que tu equipo aún no ha adoptado pruebas automatizadas?
Discutámoslo en LinkedIn o X.


Referencias


💡 Bonus: Checklist de Calidad

¿Quieres asegurarte de que tu aplicación cumple con todos los estándares?
Descarga nuestra Checklist de Pruebas Automatizadas para Oracle APEX y
lleva tu desarrollo al siguiente nivel.

👉 Descargar Checklist (PDF)


🚀 ¿Necesitas un Experto en APEX?

Ayudo a empresas a facilitar el desarrollo profesional y DevOps en Oracle APEX.
Si quieres construir mejores aplicaciones o automatizar tu pipeline, hablemos.

☕ Agendar un Café
💼 Conectar en LinkedIn
🐦 Seguir en X

💖 Apoya mi Trabajo

Si encontraste útil este APEX Insight, ¡considera apoyarme!

GitHub Sponsors | Buy Me a Coffee

Tu apoyo me ayuda a seguir creando demos open-source y contenido para la
comunidad de Oracle APEX. 🚀

Top comments (0)