devKing de ALS

devKing es una herramienta que realiza análisis estático de código, análisis de dependencias, y generación, ejecución y análisis de cobertura de pruebas unitarias.

Análisis estático

devKing for J2EE applications es una herramienta pensada para facilitar y automatizar el proceso de adopción de los estándares de calidad y buenas prácticas del código Java, JSP, JavaScript, HTML y XML.

Prevención automática de errores

Los estándares de codificación son reglas específicas de cada lenguaje de programación, cuyo cumplimiento reduce de forma significativa, la posibilidad de cometer errores no detectados por los compiladores.

Al implementar y verificar el cumplimiento de estos estándares de codificación, se evitan los errores en la introducción del código, reduciendo el tiempo y coste de las actividades de depuración y pruebas necesarias para la detección y corrección de los mismos.

Adopción de estándares de codificación

No obstante, la adopción de estos estándares para un departamento entero de desarrollo, puede resultar un proceso largo y tedioso, si no se cuenta con la ayuda de alguna herramienta que facilite y automatice este trabajo.

Eso es lo que ha llevado a muchas organizaciones a adoptar devKing, herramienta que ALS ha elaborado, con cientos de reglas que ofrecen la capacidad de prevenir los errores y estandarizar el código de forma automática.

Agrupación y configuración de reglas

Estas reglas se agrupan en categorías (optimización y rendimiento, seguridad, normas generales de codificación, portabilidad, normas J2EE...)

Cada regla tiene una prioridad que indica su grado de criticidad. Estas prioridades son valores configurables por el usuario.

Pruebas Unitarias

"Normalmente no hay tiempo para implementar la funcionalidad de la aplicación, como para codificar y preparar las pruebas unitarias."

Esta frase que se puede escuchar a menudo en los equipos de desarrollo software refleja el nivel actual de realización de las pruebas unitarias del código que se desarrolla.

Al realizar las pruebas unitarias, se aísla cada parte del código para garantizar que el funcionamiento de cada uno de sus módulos es correcto. Son las primeras pruebas que el equipo de desarrollo debe realizar.

Framework JUnit

Contar con un framework de pruebas unitarias, como por ejemplo JUnit, es útil y potente, sin embargo, realizan su ejecución.

La generación de los casos de prueba para cada función o método importante en el código, es una tarea vital pero pesada y tediosa, por lo que se hace necesario su automatización.

Generación automática de pruebas unitarias

devKing for J2EE applications, mediante la generación automática de pruebas unitarias, basado en combinatoria de los valores de los parámetros de entrada, permite al programador ahorrar gran cantidad de horas de elaboración de las pruebas unitarias de forma manual.

Los métodos que implementa el programador reciben todo tipo de parámetros, tipos primitivos (enteros, flotas, chars...) u objetos tanto internos de Java como de la propia lógica de negocio de la aplicación. Mediante el algoritmo de generación de casos de pruebas, proporcionado en devKing, el programador obtendrá un abanico de pruebas que probarán los métodos desarrollados.

Detección de errores

Las pruebas generadas se ejecutan apoyándose en el framework JUnit. El lanzamiento de esta batería de pruebas sobre los métodos implementados, provoca la detección de errores y comportamientos inesperados de la aplicación.

Estas pruebas permiten detectar errores como: excepciones no capturadas (NullPointerExcepcion, ArrayIndexOutOfBoundsException...), errores en tiempo de ejecución (OutOfMemoryError), o cuelgues de la aplicación controlados mediante un timeout.

Informes

El módulo de pruebas unitarias de devKing ofrece, tras la ejecución de las pruebas, informes integrados en el entorno de desarrollo, con los errores que se han producido durante las pruebas, indicando el problema y su causa.

Análisis de cobertura

Además de automatizar las pruebas unitarias, devKing ofrece un análisis de cobertura de las pruebas, que permite conocer qué parte del código ha sido "cubierto" por las pruebas unitarias que se han ejecutado.

Distintos niveles de cobertura

Para cada uno de los elementos probados se muestran dos niveles de cobertura: cobertura a nivel de línea y cobertura a nivel de rama.

El primero hace referencia al número de líneas que se han cubierto en las pruebas.

El segundo hace referencia a las posibles bifurcaciones o caminos, en base a las condiciones (if-else, switch-case...) que existen en el código.

Informes

El análisis de cobertura presenta un informe HTML con los resultados para cada uno de los paquetes analizados por devKing.

Para cada uno de ellos se permitirá, mediante drill down, ver los resultados de cobertura de las clases que lo componen.

Ordenación de clases

Los informes contemplan la opción de ordenar las clases analizadas en función del nivel de cobertura alcanzado.

Esta funcionalidad es útil para detectar, de un simple vistazo, aquellos elementos con un nivel de cobertura pobre.

Informe línea a línea

El análisis de cobertura arroja un nivel de detalle exhaustivo, al ofrecer una vista línea a línea del código:

• Líneas que nunca se han ejecutado.
• Código por el que las pruebas no han conseguido pasar.
• Posible código muerto.

Código de colores

Este tipo de líneas se mostrarán en color rojo, mientras que las líneas por las que se pasa al menos una vez se pintan en color verde, indicando a la izquierda de la misma el número de veces que se ha ejecutado.

Análisis de dependencias

El módulo de análisis de dependencias de devKing, ofrece una visión clara del grado de acoplamiento del código, detectando el nivel de dependencia de cada una de las clases.

Permite al programador revisar el diseño atendiendo a la jerarquía UML de su aplicación y estudiando las relaciones de dependencias resultantes.

Dependencias circulares

Cuando una clase A invoca una clase B, ésta a una clase C y finalmente la clase C vuelve a invocar a la clase inicial A, se trata de una relación de dependencia circular entre las tres clases. Las dependencias circulares incumplen los estándares de mantenibilidad y acoplamiento de una aplicación, ya que dificulta su legibilidad, mantenimiento y rediseño en un futuro. devKing detecta este tipo de dependencias indicando en el grafo las clases relacionadas.

Coeficientes de dependencia

devKing, además, muestra un informe, en el que para cada clase analizada se muestra información de coeficientes propios de dependencia.

El coeficiente de eferencia (Ce) indica el número de veces que la clase en cuestión llama a otras clases, por el contrario, el coeficiente de aferencia (Ca) expresa el número de veces que se invoca a la clase en cuestión.

Por último, el índice de mantenibilidad (I) indica lo fácil o difícil que es mantener una clase en un futuro en función de las dependencias que tiene.

devKing facilita el análisis de una petición de cambio de una determinada funcionalidad, ya que, de un simple vistazo, el usuario, podrá ver el impacto que conlleva modificar una clase viendo a que métodos de otras clases está invocando.