java - Herramienta de análisis de dependencias-actualización de casos de prueba de regresión.

testing dependencies

Question

Problema

Es un problema bastante común que me gustaría pensar. Agregar nuevo código se traduce en regresión: los casos de prueba existentes se vuelven obsoletos. Las dependencias dentro del código significan que incluso si sabe cómo arreglar esta regresión en particular, podría haber una regresión indirecta en n más lugares en ambas direcciones: Aferente y Eferente.

Requisito

Tengo una tienda que maneja SVN, Maven + Nexus, Sonar, Jenkins y JIRA, QC, QTP. En general, un buen ambiente de CI.

Con cada nueva construcción tendré nuevos casos de regresión. Quiero encontrar las dependencias de paquetes Java en ambas direcciones y actualizar los casos de prueba correctamente para cubrir todos los tipos de regresión, directa e indirecta. Esto es más un problema, ya que la cobertura de mi prueba de unidad ni siquiera se acerca al 50% y la automatización de las pruebas de integración no está a la par con el desarrollo.

Mis opciones

1. SONAR
2. Google CodePRo
3. JArchitect
4. Jtest (tuvo una discusión con el vendedor Parasoft. No tienen una herramienta para esto)
5. Aproveche el entorno existente que tengo con, digamos, un complemento de Atlassian
6. Kalisitck (Demostración del proveedor - Herramienta agradable - implica una curva de aprendizaje y un costo)
7. Cobertura (como Kalistick: curva de aprendizaje e instalación compleja. Licencia muy costosa.
8. ¿Algún otro código abierto / pagado?

JArchitect, SONAR y CodePro te darán una matriz simple como this o this . Lo que satisface la mitad de mi requerimiento al decirme qué clases de usuario y de uso se ven afectadas. Lo que quiero es ir un paso más allá y hacer que la herramienta me diga qué casos de prueba correspondientes se ven afectados y si necesito actualizarlos y / o ejecutarlos para cubrir mis riesgos de regresión.

Kalistick, Coverity y quizás otros hagan lo que yo quiera: son pesados ​​de configurar y configurar, crecen lentamente con su sistema, por lo que no son productivos de inmediato, tienen un costo y necesitan una curva de aprendizaje.

Pregunta corta

Qué herramienta (s) de arriba usar en mi configuración considerando todos los factores como instalación, curva de aprendizaje, costo, disponibilidad o cualquier otro parámetro.

Ya he leído la sección de preguntas frecuentes sobre static-analysis , ¿algunos hilos como la recomendación de la herramienta Análisis estático para Java? , https://stackoverflow.com/questions/3716203/automatic-code-quality-and-architecture-quality-static-code-analysis y ¿Qué es la fascinación por las métricas de código? y muchos vinculados, pero no responden a mi pregunta específica.

Answer 1

Algunas herramientas que podrían ayudar. Tenga en cuenta que no todos ellos se integran con CI.

iPlasma es una gran herramienta

CodePro es un complemento de Eclipse que ayuda a detectar problemas de código y diseño (por ejemplo, código duplicado, clases que rompen la encapsulación o métodos colocados en una clase incorrecta). (Ahora adquirido por Google )

Relief es una herramienta que visualiza los siguientes parámetros de los proyectos Java: tamaño de un paquete, es decir, cuántas clases e interfaces contiene el tipo de elemento que se visualiza (los paquetes y las clases se representan como cuadros, interfaces y campos de tipo como esferas). la cantidad de dependencias (representadas como profundidad) se está utilizando (se representa como la gravedad, es decir, la distancia del centro).

Stan4j es una herramienta comercial que cuesta un par de cientos de dólares. Está dirigido solo a proyectos Java, se acerca mucho (o un poco mejor a los informes que? No estoy seguro) de Sonar. Tiene una buena integración con Eclipse.

Análisis de dependencia de Intellij

Por lo que pude entender de su problema es que, debe realizar un seguimiento de dos métricas de OO: Acoplamiento eferente (Ca) y Acoplamientos aferentes (Ce) . Con esto usted puede reducir a los paquetes requeridos. Puede explorar la oportunidad de escribir un complemento de eclipse que en cada compilación puede resaltar las clases requeridas en función de las métricas de Ca, Ce.

Answer 2

Con JDepend puede analizar las dependencias entre paquetes e incluso crear pruebas unitarias para asegurar las dependencias o integrarlo con Fitnesse para tener una buena prueba de la tabla de dependencias. Esto puede ayudar, si sus pruebas están en paquetes específicos ...

Answer 3

La mejor herramienta que puede encontrar para su problema en realidad no es una herramienta, sino una práctica. Le sugiero que lea acerca de Test Driven Development (ver el libro de Lasse Koskela ) y Specification by Example (vea los libros de Gojko Adzic , son geniales).

Usar estas prácticas cambiará fundamentalmente dos cosas:

1. Tendrás una cobertura de prueba cercana al 100%.
2. Las pruebas se convertirán en ciudadanos de primera clase y serán el punto central de su código.

La razón por la que encuentro esto relevante para su pregunta es que su escenario sugiere la función exactamente opuesta a las pruebas: las personas realizarán cambios en el código y luego pensarán "oh, no ... ahora tengo que descubrirlo. Lo que rompí en esas malditas pruebas ".

Desde mi experiencia, las pruebas no deben pasarse por alto o considerarse "código de grado inferior". Y mientras mi respuesta apunta a un cambio de metodología que solo tendrá resultados visibles a largo plazo, podría ayudar a evitar el problema por completo en el futuro.

Answer 4

Puede encontrar hasta dependencias de nivel de clase utilizando Classycle-Dependency Checker . Y la sección - Comprobar la dependencia de clases en la guía puede ayudar en su caso. Sin embargo, normalmente, utilizando una herramienta de análisis estático, analizamos ya sea la base de código fuente (por ejemplo: Project-> src directory) o la base de código de prueba (por ejemplo: Project-> test directory) pero no ambas. Pero en su caso, parece que también quiere averiguar las dependencias entre el código fuente y el código de prueba. Por lo tanto, lo que necesita es ejecutar una herramienta de análisis de dependencia adecuada al proporcionar la ruta de entrada como ruta principal tanto de src como de prueba (por ejemplo, el directorio raíz del proyecto) (por ejemplo: usar dependencias averiguar -> si la fuente X cambia, qué Las clases dependientes en las pruebas se ven afectadas por ese cambio).

Answer 5

Puedes averiguar qué pruebas son relevantes siguiendo el código que tocan. Puede rastrear qué código tocan usando herramientas de cobertura de prueba.

La mayoría de las herramientas de cobertura de prueba crean un conjunto explícito de ubicaciones que ejecuta una prueba en ejecución; Ese es el punto de "cobertura". Si organiza la ejecución de la prueba para ejecutar una prueba de unidad a la vez y luego toma una instantánea de los datos de cobertura, entonces sabe para cada prueba qué código cubre.

Cuando se modifica el código, puede determinar la intersección del código modificado y lo que cubre una prueba individual. Si la intersección no está vacía, seguramente necesitará ejecutar esa prueba nuevamente, y probablemente necesitará actualizarla.

Hay varios problemas prácticos para hacer este trabajo.

Primero, a menudo es difícil entender cómo las herramientas de cobertura de prueba registran estos datos de posicionamiento. En segundo lugar, debe obtener el mecanismo de prueba para capturarlo por prueba; eso puede ser difícil de organizar y / o los datos de cobertura pueden ser torpes de extraer y almacenar. En tercer lugar, debe calcular la intersección de "código modificado" con "código cubierto" por una prueba; esto es, en gran medida, un problema abstracto en la intersección de vectores de bits grandes. Finalmente, capturar "código modificado" es un poco complicado porque a veces el código se mueve ; si se probó la ubicación 100 en un archivo y la línea se mueve en el archivo, es posible que no obtenga datos de posición comparables. Eso conducirá a falsos positivos y falsos negativos.

Existen herramientas de cobertura de prueba que registran los datos de cobertura en una forma fácilmente capturada, y pueden hacer los cálculos. Determinar los cambios de código es más complicado; puede usar diff pero el código movido confundirá un poco el problema. Puede encontrar herramientas de diferencias que comparan las estructuras de código, que identifican dichos movimientos, para que pueda obtener mejores respuestas.

Si tiene segmentaciones de código fuente , puede calcular cómo la salida probada depende (rebanada hacia atrás) de la entrada; Todo el código en esa porción afecta la prueba, obviamente. Creo que la mala noticia aquí es que tales máquinas de cortar no son fáciles de obtener.

Answer 6

Si leo la pregunta correctamente, desea una herramienta que analice el código fuente y determine qué pruebas no necesitan ser ejecutadas nuevamente.

Lo primero que hay que considerar es ¿cuál es el problema con ejecutar siempre todas las pruebas ? Eso es lo que significa CI. Si no puede ejecutar todas sus pruebas de unidad en 15 minutos y todas sus pruebas de integración / estrés durante la noche, resuelva el problema que sea el caso, probablemente comprando algún hardware.

Si esto falla, lo único que puede rastrear la posible regresión de la prueba es el análisis de cobertura (por ejemplo, http://www.eclemma.org/ ). Dado el diseño básico de OO, y mucho menos la inyección de dependencias, el paquete estático o las dependencias de clase son, en el mejor de los casos, sin sentido y, probablemente, confusos, en términos de qué cambios pueden hacer que las pruebas fallen. Y eso es ignorar el caso donde el problema es que A debería estar llamando a B, y no lo es. Sin embargo, los archivos cambiados de referencia cruzada con los archivos llamados y si no hay una intersección, tal vez no volver a ejecutar la prueba es posiblemente seguro, las fallas restantes serán cosas como algún código que agregue un controlador de eventos donde no había uno antes.

No creo que haya una herramienta gratuita para hacer esto, pero debería poder ser ejecutada por Jenkins / Emma / Git. O utilice una de las soluciones integradas como Kalistick. Pero sería escéptico de que podría superar de manera eficiente el juicio humano basado en la comunicación con el equipo de desarrollo en cuanto a lo que están tratando de hacer .

En una nota vagamente relacionada, la herramienta simple que el mundo de Java realmente necesita, pero no existe, es una extensión de junit que ejecuta un conjunto de pruebas en orden de dependencia y se detiene en el primer error. Eso proporcionaría un poco de ayuda adicional para permitir que un desarrollador se centre en la fuente más probable de una regresión.

Answer 7

Yo mismo soy un gran fan de Sonar, ya que ya lo tienes funcionando y trabajando en tu entorno de CI, esa sería mi sugerencia. No estoy muy seguro de cómo la Matriz de Ciclo de Dependencia de Sonar ya no hace lo que quieres, o más bien lo que quieres además de eso.