{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Pruebas unitarias en DBMS: c\u00f3mo lo hacemos en Sportmaster, parte dos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La primera parte \u2014 aqu\u00ed<\/a><\/noindex>.<\/i><\/p>\n

\"Pruebas<\/a><\/noindex><\/p>\n

Imagina la situaci\u00f3n. Tienes la tarea de desarrollar una nueva funcionalidad. Cuentas con los avances de tus predecesores. Si asumimos que no tienes ninguna obligaci\u00f3n moral, \u00bfc\u00f3mo proceder\u00edas?<\/p>\n

Con frecuencia, todos los antiguos desarrollos caen en el olvido y todo comienza desde cero. Nadie quiere hurgar en el c\u00f3digo ajeno, y si hay tiempo, \u00bfpor qu\u00e9 no dedicarse a crear un sistema propio? Este es un enfoque t\u00edpico y, en gran medida, correcto. Pero en nuestro proyecto no hicimos eso. Basamos el futuro sistema de pruebas autom\u00e1ticas en los desarrollos de pruebas unitarias en utPLSQL de nuestros predecesores y luego comenzamos a trabajar en varias direcciones paralelas.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Recuperaci\u00f3n de antiguas pruebas unitarias.<\/b> Por recuperaci\u00f3n se entiende la adaptaci\u00f3n de las pruebas al estado actual del sistema de lealtad y la adaptaci\u00f3n de las pruebas a los est\u00e1ndares de utPLSQL. <\/li>\n
  2. La soluci\u00f3n al problema de la comprensi\u00f3n de qu\u00e9 m\u00e9todos y procesos est\u00e1n cubiertos por las pruebas autom\u00e1ticas. <\/b>Hay que mantener esta informaci\u00f3n en la cabeza o sacar conclusiones directamente del c\u00f3digo de las pruebas autom\u00e1ticas. Por eso decidimos crear un cat\u00e1logo. A cada prueba autom\u00e1tica le asignamos un c\u00f3digo mnemot\u00e9cnico \u00fanico, creamos una descripci\u00f3n y registramos la configuraci\u00f3n (por ejemplo, en qu\u00e9 condiciones debe ejecutarse o qu\u00e9 debe suceder si la ejecuci\u00f3n de la prueba falla). En esencia, completamos los metadatos de las pruebas autom\u00e1ticas y los colocamos en las tablas est\u00e1ndar del esquema de utPLSQL.<\/li>\n
  3. Definici\u00f3n de la estrategia de expansi\u00f3n, es decir, la elecci\u00f3n de las funcionalidades que ser\u00e1n verificadas por las pruebas autom\u00e1ticas.<\/b> Decidimos centrarnos en tres aspectos: las nuevas mejoras del sistema, los incidentes en producci\u00f3n y los procesos clave del sistema. De esta manera, evolucionamos paralelamente al lanzamiento, mejorando su calidad, ampliamos el volumen de regresiones y garantizamos la fiabilidad del sistema en lugares cr\u00edticos. El primer punto cr\u00edtico fue el proceso de distribuci\u00f3n de descuentos y bonificaciones en los recibos.<\/li>\n
  4. Por supuesto, nos dedicamos al desarrollo de nuevas pruebas autom\u00e1ticas. <\/b>Una de las primeras tareas del lanzamiento fue evaluar el rendimiento de las muestras predefinidas del sistema de lealtad. En nuestro proyecto, hay un bloque de consultas SQL r\u00edgidamente definidas que seleccionan clientes seg\u00fan ciertos criterios. Por ejemplo, obtener una lista de todos los clientes cuya \u00faltima compra se realiz\u00f3 en una ciudad espec\u00edfica, o una lista de clientes cuya media de compra supera un valor determinado. Al escribir pruebas autom\u00e1ticas, verificamos las muestras predefinidas, registramos los par\u00e1metros de rendimiento de referencia y, adem\u00e1s, realizamos pruebas de carga.<\/li>\n
  5. El trabajo con pruebas autom\u00e1ticas debe ser conveniente.<\/b>. Las acciones m\u00e1s comunes son: ejecutar pruebas autom\u00e1ticas y crear datos de prueba. As\u00ed, en nuestro sistema surgieron dos m\u00f3dulos auxiliares: un m\u00f3dulo de ejecuci\u00f3n y un m\u00f3dulo de generaci\u00f3n de datos.\n

    El m\u00f3dulo de ejecuci\u00f3n se presenta como un procedimiento universal con un \u00fanico par\u00e1metro de texto de entrada. Como par\u00e1metro, se puede pasar el c\u00f3digo mnemot\u00e9cnico de la prueba autom\u00e1tica, el nombre del paquete, el nombre de la prueba, la configuraci\u00f3n de la prueba autom\u00e1tica o una palabra clave reservada. El procedimiento selecciona y ejecuta todas las pruebas autom\u00e1ticas que cumplen con las condiciones.<\/p>\n

    El m\u00f3dulo de generaci\u00f3n de datos se presenta como un paquete, en el cual para cada objeto del sistema en prueba (tabla en la base de datos), se cre\u00f3 un procedimiento especial que inserta datos all\u00ed. En este procedimiento, se maximizan los valores predeterminados, lo que permite crear objetos literalmente con un chasquido de dedos. Y para comodidad de uso, se crearon plantillas de datos generados. Por ejemplo, crear un cliente de cierta edad con un tel\u00e9fono de prueba y una compra realizada.<\/li>\n

  6. Las pruebas autom\u00e1ticas deben iniciarse y funcionar en un tiempo aceptable para su sistema. <\/b>Por lo tanto, se organiz\u00f3 un lanzamiento diario nocturno, cuyos resultados se recopilan en un informe que se env\u00eda a todo el equipo de desarrollo a trav\u00e9s del correo corporativo. Despu\u00e9s de restaurar las pruebas autom\u00e1ticas antiguas y crear nuevas, el tiempo total de operaci\u00f3n fue de 30 minutos. Este nivel de rendimiento fue satisfactorio para todos, ya que la ejecuci\u00f3n se realizaba fuera del horario laboral.\n

    Sin embargo, se tuvo que trabajar en la optimizaci\u00f3n de la velocidad. La actualizaci\u00f3n del sistema de lealtad en producci\u00f3n se realiza por la noche. Durante uno de los lanzamientos, se tuvieron que hacer cambios de emergencia en medio de la noche. La media hora de espera por los resultados de las pruebas autom\u00e1ticas a las tres de la ma\u00f1ana no hizo feliz al responsable del lanzamiento (un saludo c\u00e1lido a Alexey Vasyukov), y a la ma\u00f1ana siguiente se dijeron muchas cosas amables sobre nuestro sistema. Sin embargo, al final se estableci\u00f3 un est\u00e1ndar de 5 minutos para el funcionamiento.<\/p>\n

    Para acelerar el rendimiento, utilizamos dos m\u00e9todos: las pruebas autom\u00e1ticas se ejecutan en tres flujos paralelos, lo cual es muy conveniente debido a la arquitectura de nuestro sistema de lealtad. Y abandonamos el enfoque en el que la prueba autom\u00e1tica no crea datos de prueba para s\u00ed misma, sino que intenta encontrar algo adecuado en el sistema. Despu\u00e9s de realizar estos cambios, el tiempo total de ejecuci\u00f3n se redujo a 3-4 minutos.<\/li>\n

  7. El proyecto de pruebas autom\u00e1ticas debe poder desplegarse en diferentes entornos.<\/b> Al principio, intentamos escribir nuestros propios scripts, pero nos dimos cuenta de que una instalaci\u00f3n automatizada hecha a mano es un verdadero desastre, as\u00ed que nos orientamos hacia soluciones industriales. Dado que hay mucho c\u00f3digo en el proyecto (principalmente almacenamos el c\u00f3digo de las pruebas autom\u00e1ticas) y pocos datos (los datos principales son metadatos sobre las pruebas autom\u00e1ticas), la implementaci\u00f3n de Liquibase en el proyecto result\u00f3 ser muy sencilla.\n

    Es una biblioteca independiente de la base de datos de c\u00f3digo abierto para rastrear, gestionar y aplicar cambios en el esquema de la base de datos. Se gestiona a trav\u00e9s de la l\u00ednea de comandos o de marcos como Apache Maven. El principio de funcionamiento de Liquibase es bastante simple. Tenemos un proyecto organizado de cierta manera, que consiste en cambios o scripts que se deben aplicar al servidor de destino, y archivos de control que determinan en qu\u00e9 orden y con qu\u00e9 par\u00e1metros se deben instalar dichos cambios. <\/p>\n

    A nivel de la base de datos, se crea una tabla especial donde Liquibase almacena el registro de las implementaciones. Cada cambio tiene un hash calculado que se compara cada vez entre el proyecto y el estado en la base de datos. Gracias a Liquibase, implementamos f\u00e1cilmente los cambios en nuestro sistema en cualquier entorno. Las pruebas autom\u00e1ticas se ejecutan actualmente en entornos de prueba y de lanzamiento, as\u00ed como en contenedores (entornos personales de desarrolladores).<\/li>\n<\/ol>\n

    \"Pruebas
    \n
    \nAs\u00ed que hablemos sobre los resultados de la aplicaci\u00f3n de nuestro sistema de pruebas unitarias. <\/p>\n

      \n
    1. Por supuesto, en primer lugar, estamos convencidos de que hemos comenzado a desarrollar software de mejor calidad. Las pruebas autom\u00e1ticas se ejecutan diariamente y en cada lanzamiento, detectando decenas de errores. Adem\u00e1s, parte de estos errores est\u00e1n solo indirectamente relacionados con la funcionalidad que realmente quer\u00edamos cambiar. Hay serias dudas de que estos errores fueron encontrados a trav\u00e9s de pruebas manuales. <\/li>\n
    2. El equipo ha ganado confianza en que una funcionalidad espec\u00edfica funciona correctamente... Esto se aplica en primer lugar a nuestros procesos cr\u00edticos. Por ejemplo, en los \u00faltimos seis meses no hemos tenido problemas con la distribuci\u00f3n de descuentos y bonos en el ticket, a pesar de los cambios en cada lanzamiento, aunque en per\u00edodos anteriores los errores ocurr\u00edan con cierta periodicidad.<\/li>\n
    3. Hemos logrado reducir la cantidad de iteraciones de pruebas. Gracias a que las pruebas autom\u00e1ticas se escriben para nueva funcionalidad, los analistas y, por su parte, los testers reciben c\u00f3digo de mayor calidad, ya que ha sido verificado.<\/li>\n
    4. Parte de los desarrollos de pruebas automatizadas es utilizada por los desarrolladores. Por ejemplo, los datos de prueba en los contenedores se generan mediante un m\u00f3dulo de generaci\u00f3n de objetos.<\/li>\n
    5. Es importante destacar que hemos logrado una aceptaci\u00f3n del sistema de pruebas automatizadas por parte de los desarrolladores. Existe un entendimiento de que es importante y \u00fatil. Y por experiencia propia, puedo decir que no siempre es as\u00ed. Las pruebas autom\u00e1ticas deben escribirse, mantenerse y desarrollarse, analizar los resultados, y a menudo, este tiempo invertido simplemente no vale la pena. Es mucho m\u00e1s f\u00e1cil ir al entorno de producci\u00f3n y all\u00ed resolver los problemas. Sin embargo, nuestros desarrolladores hacen fila y piden que cubramos su funcionalidad con pruebas autom\u00e1ticas.<\/li>\n<\/ol>\n

      \u00bfQu\u00e9 sigue?<\/h2>\n

      \n\"Pruebas
      \n
      \nHablemos sobre los planes de desarrollo del proyecto de pruebas automatizadas.<\/p>\n

      Sin duda, mientras el sistema de lealtad de Sportmaster est\u00e9 vivo y en constante desarrollo, tambi\u00e9n se pueden desarrollar pr\u00e1cticamente de forma infinita las pruebas automatizadas. Por lo tanto, la principal direcci\u00f3n de desarrollo es la expansi\u00f3n de la cobertura.<\/p>\n

      A medida que aumenta la cantidad de pruebas automatizadas, el tiempo total de su ejecuci\u00f3n tambi\u00e9n crecer\u00e1 de manera invariable, y deberemos volver a abordar la cuesti\u00f3n del rendimiento. Lo m\u00e1s probable es que la soluci\u00f3n radique en aumentar la cantidad de hilos paralelos.<\/p>\n

      Pero estos son caminos evidentes de desarrollo. Si hablamos de algo m\u00e1s no trivial, destaquemos lo siguiente:<\/p>\n

        \n
      1. Actualmente, la gesti\u00f3n de las pruebas automatizadas se realiza a nivel de base de datos, es decir, se necesitan conocimientos de PL\/SQL para un funcionamiento exitoso. Si es necesario, la gesti\u00f3n del sistema (por ejemplo, ejecutar lanzamientos o crear metadatos) se puede delegar a alg\u00fan panel de administraci\u00f3n, utilizando Jenkins o algo similar.<\/li>\n
      2. A todos les gustan los indicadores cuantitativos y cualitativos. Para las pruebas autom\u00e1ticas, un indicador universal es la cobertura de c\u00f3digo o la m\u00e9trica de cobertura de c\u00f3digo. Con esta m\u00e9trica podemos determinar qu\u00e9 porcentaje del c\u00f3digo de nuestro sistema en prueba est\u00e1 cubierto por pruebas automatizadas. A partir de la versi\u00f3n 12.2, Oracle ofrece capacidades para el c\u00e1lculo de esta m\u00e9trica y sugiere usar el paquete est\u00e1ndar DBMS_PLSQL_CODE_COVERAGE.\n

        Nuestro sistema de pruebas automatizadas tiene poco m\u00e1s de un a\u00f1o y, tal vez, ahora sea el momento adecuado para evaluar la cobertura. En mi proyecto anterior (no el de Sportmaster) ocurri\u00f3 as\u00ed. Un a\u00f1o despu\u00e9s de trabajar en pruebas automatizadas, la direcci\u00f3n estableci\u00f3 la tarea de evaluar qu\u00e9 porcentaje de c\u00f3digo est\u00e1 cubierto. Con una cobertura de m\u00e1s del 1%, la direcci\u00f3n estar\u00eda satisfecha. Nosotros, los desarrolladores, esper\u00e1bamos un resultado cercano al 10%. Activamos la cobertura de c\u00f3digo, medimos y obtuvimos un 20%. Con la alegr\u00eda, fuimos a buscar una bonificaci\u00f3n, pero c\u00f3mo la conseguimos y a d\u00f3nde fuimos despu\u00e9s, es toda otra historia.<\/li>\n

      3. Las pruebas automatizadas pueden verificar los servicios web expuestos. Oracle permite hacer esto, y ya no enfrentaremos una serie de problemas. <\/li>\n
      4. Y, por supuesto, nuestro sistema de pruebas automatizadas se puede aplicar a otros proyectos. La soluci\u00f3n que hemos obtenido es universal y solo requiere el uso de Oracle. He o\u00eddo que en otros proyectos de Sportmaster hay inter\u00e9s en las pruebas automatizadas y, posiblemente, nos dirigiremos hacia ellos.<\/li>\n<\/ol>\n

        <\/p>\n

        Conclusiones<\/h2>\n

        \nResumamos. En el proyecto del sistema de lealtad de Sportmaster, logramos implementar un sistema de pruebas automatizadas. Su base es la soluci\u00f3n utPLSQL de Steven Feuerstein. Alrededor de utPLSQL se encuentra el c\u00f3digo de las pruebas autom\u00e1ticas y m\u00f3dulos auxiliares hechos a medida: m\u00f3dulo de lanzamiento, m\u00f3dulo de generaci\u00f3n de datos y otros. Las pruebas autom\u00e1ticas se ejecutan diariamente y, lo que es m\u00e1s importante, funcionan y aportan beneficios. Estamos convencidos de que hemos comenzado a lanzar software de mayor calidad. Adem\u00e1s, la soluci\u00f3n obtenida es universal y puede aplicarse libremente a cualquier proyecto donde sea necesario implementar pruebas automatizadas en la base de datos Oracle.<\/p>\n

        P.D. Este art\u00edculo result\u00f3 no ser muy concreto: hay mucho texto y pr\u00e1cticamente no hay ejemplos t\u00e9cnicos. Si a grandes rasgos el tema es interesante, estamos dispuestos a continuar y volver con una continuaci\u00f3n, donde contaremos qu\u00e9 ha cambiado en los \u00faltimos seis meses y proporcionaremos ejemplos de c\u00f3digo.<\/p>\n

        Escriban comentarios si hay aspectos que merece destacar en el futuro, o preguntas que requieran aclaraci\u00f3n.<\/i><\/p>\n

        Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a><\/noindex>, por favor.<\/p>\n

        \u00bfSeguimos escribiendo sobre esto?<\/h2>\n