Graduado en Ingeniería Informática

Universidad Politécnica de Madrid

Escuela Técnica Superior deIngenieros Informáticos

TRABAJO FIN DE GRADO

ToraDocu – Generacion automática de casos de test conoráculos: Precondiciones y postcondiciones.

Autor: Sergio Delgado

Director: Damiano Zanardini

Director empresa: Alessandra Gorla

MADRID, JUNIO DE 2017

ÍNDICE1. Introducción 1

2. Estado del arte 22.1. Automatización de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2. Generación automática de tests . . . . . . . . . . . . . . . . . . . . . . . 2

2.3. Generación automática de oráculos . . . . . . . . . . . . . . . . . . . . . 3

3. ToraDocu 43.1. Extractor de Javadoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2. Traductor de condiciones . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3. Generador de oráculos . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4. Plataforma de Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4. Funcionalidades añadidas 114.1. Soporte para los Param tags . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1. Análisis de patrones . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.2. Extracción y traducción de @param . . . . . . . . . . . . . . . . 13

4.1.3. Modificación de la plataforma de test y mejoras del análisis . . . 14

4.2. Soporte para los Return tags . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.1. Análisis de patrones . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.2. Extracción y traducción de @return . . . . . . . . . . . . . . . . 17

4.2.3. Modificación de la plataforma de test y mejoras . . . . . . . . . . 18

5. Evaluación y test 195.1. Estado previo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2. Estado actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.3. Caso real: Uso de ToraDocu . . . . . . . . . . . . . . . . . . . . . . . . 19

6. Trabajo futuro 24

7. Conclusiones 25

I

ÍNDICE DE FIGURAS1. Esquema general de ToraDocu . . . . . . . . . . . . . . . . . . . . . . . 4

2. Condiciones del @param en Commons Collections . . . . . . . . . . . . 20

3. Condiciones del @throws en Commons Collections . . . . . . . . . . . . 20

4. Condiciones del @return en Commons Collections . . . . . . . . . . . . 21

5. Condiciones del @param en Commons Math3 . . . . . . . . . . . . . . . 21

6. Condiciones del @throws en Commons Math3 . . . . . . . . . . . . . . 21

7. Condiciones del @return en Commons Math3 . . . . . . . . . . . . . . . 22

8. Condiciones del @param en Plume Lib . . . . . . . . . . . . . . . . . . 23

9. Condiciones del @throws en Plume Lib . . . . . . . . . . . . . . . . . . 23

10. Condiciones del @return en Plume Lib . . . . . . . . . . . . . . . . . . . 23

ÍNDICE DE TABLAS

II

Resumen

Normalmente, los desarrolladores documentan su código con comenta-

rios semiestructurados, como son los JavaDoc. Esos comentarios son los que

describen el funcionamiento del programa, así como en la gran mayoría de

casos, propiedades y condiciones a cumplir de parámetos de entrada y salida.

El objetivo del proyecto es usar dicha información y analizarla para generar

de forma automática aserciones y test con oráculo. Así pues, con estos ele-

mentos, seríamos capaces de generar los test de dicha clase Java, únicamente

basándonos en los comentarios que tenemos, sin tener que programarlos ma-

nualmente, ahorrando en tiempo y costes.

Palabras clave: testing, oráculos de test, JavaDoc, aserciones.

Abstract

Usually, the developers in a project documents their code with semi-

structured comment, such as JavaDoc. Those comments are the ones that

describes the program behavior, and in almost every time, the properties and

conditions that the input and output parameters have to pass. The main pur-

pose of the project is, using and analyzing this information, to generate auto-

matically assertions and oracle test. With this elements, we would be able to

generate the tests of that Java class only with the comments we have in the

JavaDoc part, without having to programming those tests manually, saving

time and costs.

Keywords: testing, oracle tests, JavaDoc, assertions.

III

1. INTRODUCCIÓNHoy en día, el problema del testeo de software es de las partes más importantes en

todo proyecto. Llevar a cabo las operaciones de testeo del software creado (O en proceso

de), requiere de tres recursos básicos:

Tiempo: No hay un tiempo límite establecido en el que el software termine de estar

testeado. Dichas pruebas se realizan durante y después de dicho proyecto, e incluso

después de sacar el producto a los consumidores. Cuanto más tarde se identifica

un error en el programa, mayor es el tiempo que éste requiere para ser arreglado,

aumentando así aún más los costes. Por eso es importante identificar los errores tan

pronto como sea posible.

Dinero: Es una de las actividades que más incrementa su porcentaje en cuanto a

gastos globales del proyecto software. Según informes recientes [1], estas cifras

ascenderían hasta el 40 % en 2018. Esto reafirma la importancia que tiene esta parte

dentro del desarrollo de software, y la necesidad de abaratar costes.

Recursos humanos: De forma habitual, esta tarea se lleva a cabo a mano, ya que sin

las aserciones necesarias, no se puede comprobar el comportamiento del programa.

Dado el alto coste de esta tarea, se han creado herramientas que facilitan el testeo de

dicho software, pero habitualmente no incluyen las aserciones (oráculo) que describen el

resultado final de la ejecución del programa.

Los oráculos son una parte esencial de los casos de test, ya que determinan si el com-

portamiento ha sido correcto o no. Éstos contienen el comportamiento intencionado del

software, por tanto, han de ser generados por un humano, o generados gracias a la infor-

mación dada por un humano, como pueden ser especificaciones formales.

Este proyecto pretende generar oráculos mediante la información que los desarrolla-

dores normalmente escriben en lenguaje natural. Partiendo de los comentarios semies-

tructurados que se encuentran en los JavaDocs de las clases java, se intenta transformar

estos comentarios en oráculos de test, y usarlos en combinación con generadores de pa-

rámetros de entrada aleatorios para generar automáticamente casos de test completos que

expongan los defectos del programa.

ToraDocu se ha centrado en el comportamiento excepcional, analizando únicamente la

parte del @throws. En este trabajo se incluye el funcionamiento en profundidad de la he-

rramienta, las labores de mejora realizadas referidas a los otros comentarios del JavaDoc

(@param y @return) así como otras mejoras, los experimentos y pruebas establecidas y

llevadas a cabo.

1

2. ESTADO DEL ARTEComo se ha comentado anteriormente, existen varias herramientas que facilitan la

tarea del test de programas y aplicaciones. Aquí se hablará brevemente de dichas herra-

mientas, qué función cumplen y cómo la llevan a cabo.

2.1. Automatización de testsEn la gran mayoría de casos, los tests tienen dos elementos fundamentales básicos, a

saber: Parámetros de entrada para la función, aserciones para los parámetros de salida.

El principal framework que se utiliza en Java es JUnit [2]. JUnit es un conjunto de

clases (framework) que permite realizar la ejecución de clases Java de manera controlada,

para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se com-

porta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor

de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá

que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado

sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el

método correspondiente.

1 @Test

2 p u b l i c vo id t e s t M u l t i p l y E x c e p t i o n ( ) {

3 MyClass t e s t e r = new MyClass ( ) ;

4 a s s e r t E q u a l s ( " R e s u l t " , r e s u l t , t e s t e r . m u l t i p l y (m1 , m2) ) ;

5 }

Listing 1: Ejemplo de JUnit

JUnit es también un medio de controlar las pruebas de regresión, necesarias cuando

una parte del código ha sido modificado y se desea ver que el nuevo código cumple con

los requerimientos anteriores y que no se ha alterado su funcionalidad después de la nueva

modificación.

2.2. Generación automática de testsEn la actualidad, existen varias herramientas generadoras de input aleatorio. Su labor

consiste en, dada una función en lenguaje Java, analizar los parámetros de entrada, y

generar de forma masiva ejecuciones de dicho método.

EvoSuite [3]. y Randoop [4]. son un ejemplo de estas herramientas.

Randoop genera tests usando feedback obtenido de tests aleatorios. Con ésta técnica

son capaces de generar aserciones para capturar cómo funciona el programa. Esto permi-

te crear pruebas de regresión, pero no pruebas que testeen el correcto funcionamiento del

programa, sólo comprueban que los cambios introducidos en el programa no cambian el

comportamiento anterior.

2

Evosuite produce para los test generados, sugerencias de posibles oráculos, añadien-

do pequeñas aserciones que resumen el comportamiento del programa. Dichas aserciones

sirven para detectar desviaciones del comportamiento esperado, y para capturar el com-

portamiento actual para así compararlo con los futuros y posibles cambios en el programa

que hagan que las cosas no funcionen. De nuevo, no hay gran diferencia entre Randoop y

Evosuite, ya que ambos lo que hacen es capturar una imagen de un programa para com-

probar que funciona como ha de funcionar en el futuro, pero no comprueban ni crean

oráculos que prueben que el programa funciona como ha de funcionar en el presente.

2.3. Generación automática de oráculosAdemás de ToraDocu, existen herramientas que sean capaz de generar oráculos de

forma automática. @tComment [5] trabaja sobre programas Java, al igual que ToraDocu,

centrándose específicamente en las condiciones referidas a valores nulos de los paráme-

tros. En primer lugar, analizan el texto en inglés del Javadoc de la clase para crear un

conjunto de propiedades de un método. En segundo lugar, se generan de forma aleatoria

test para ese método. Con esto, al ejecutar los test, se comprueban las propiedades previa-

mente descritas en el paso uno, y se reportan las inconsistencias.

ToraDocu [6], a diferencia de @tComment, trabaja con todo tipo de condiciones ade-

más de las referidas a valores nulos. ToraDocu usa comparaciones directas entre el sujeto

de la oración y los elementos de código que han de ser comprobados y predicados con

patrones predefinidos o métodos que comprueban propiedades. Por tanto, y a diferencia

de @tComment, el comentario “@throws NullPointerException if the list is empty” sería

traducible y se podría relacionar con el método que comprobara dicha condición y que tu-

viera un nombre similar, y por tanto se invocaría el método "isEmpty()" de la clase "list"

en la instancia del objeto para comprobar si está vacía o no y si se lanza la excepción.

3

3. TORADOCUToraDocu es un programa que se lanza por línea de comandos.

Los parámetros que recibe como mínimo son:

–target-class: Nombre completo con los paquetes de la clase objetivo.

–class-path: Directorio que contiene los binarios de la clase. (La clase java ya com-

pilada).

–source-dir: Directorio donde se localiza la clase.

Código aanalizar

Extractorde Javadoc

Traductorde condi-

ciones

Generadorde oráculos

Casos detest

Figura 1: Esquema general de ToraDocu

Como resume la figura, ToraDocu está dividido en tres grandes bloques:

Extractor de Javadoc: Este módulo es el encargado de extraer los comentarios de la

clase seleccionada. Los transforma y convierte a un tipo de estructura propio y que

posteriormente será manejado por el Traductor de condiciones.

Traductor de condiciones: Es el encargado de generar árboles sintácticos y semán-

ticos para analizar las frases y crear las condiciones booleanas Java necesarias para

la creación de los tests.

Generador de oráculos: El módulo que se ocupará de transformar las condiciones

en oráculos, como se explicará más adelante, usando clases jAspect.

Este proceso de ejecución está dirigido por el main, que se encarga de usar el resto de

módulos e interconectarlos entre sí. A continuación se procede a la explicación de dichos

módulos.

4

3.1. Extractor de JavadocEl javadoc son comentarios semiestructurados escritos en lenguaje natural que especi-

fican las características de un elemento del código, como puede ser un método, una clase

o paquete.

A continuación, se muestra un ejemplo de la estructura de un javadoc.

1 /**2 * Creates a new aspect for the given {@code method}.3 *4 * @param method method for which an aspect will be created5 * @param aspectName name of the file where the newly created aspect is saved6 * @throws NullPointerException if {@code method} or {@code aspectName} is null7 */8 p r i v a t e s t a t i c vo id c r e a t e A s p e c t ( DocumentedMethod method , S t r i n g aspectName )

Listing 2: Ejemplo de comentario JavaDoc

Esta tarea se lleva a cabo gracias a la API que proporciona el javadoc para extraer

dichos comentarios[7]. Ha de ser indicado que, en caso de ser un método con el JavaDoc

heredado, el JavaDoc que se analizará será el del padre, pero con los datos del hijo (Nom-

bre de método, parámetros, etc).

Por ejemplo, el tag @param indica información sobre los parámetros del método, El

@return especifica características y condiciones de los valores que devuelve el método,

y finalmente, el @throws y el @exception dan pautas e información sobre el comporta-

miento excepcional.

Una vez llamamos a nuestro extractor de javadoc, esta información se extrae y se guar-

da en las clases personalizadas creadas para ella.

La primera de ellas es el throws tag, donde se almacena el tipo de excepción el

comentario y posteriormente la condición que éste generará.

El segundo tipo de dato que se almacenará son los parámetros de la función, de los

que se guardarán nombre , tipo y su posibilidad de ser NULL.

Finalmente, el tercer y último tipo de dato que se almacenará será el método en sí,

del que se guardara tanto el nombre de dicho método como su valor de return, así

como los comentarios throws asociados y sus parámetros de entrada.

5

3.2. Traductor de condicionesEl traductor de condiciones es el encargado de transformar los comentarios en len-

guaje natural a condiciones booleanas en Java, utilizando técnicas de procesamiento del

lenguaje natural[8] y comparación de patrones.

Por ejemplo, el traductor de condiciones convertiría las condiciones “if b is grea-

ter than 0” en b>0, “if sampleList is null or is empty” en sampleList==null || sample-

List.isEmpty()==true, y "if both a and b are negative" en a<0 && b<0.

A continuación se explican las fases por las que pasa el comentario para ser traducido:

1. Eliminación de elementos redundantes:

En esta fase del traductor, se eliminan los elementos que puedan entorpecer a la hora

de generar árboles semánticos, para así darle sentido a la frase y que ésta pueda ser

analizada de forma correcta.

En este caso concreto, y para el Throws, se eliminan tanto la excepción como el "if"

inicial de la frase, transformando el comentario de ejemplo "NullPointerException

if sampleList is null or is empty" en "sampleList is null or is empty".

Esto nos permite, aparte de darle un mejor sentido a la oración, simplificarla y darle

significado, ya que la excepción se usará en el generador de oráculos (El tipo de

excepción que lanza) y el "if" hace que la oración en inglés carezca de sentido

como tal, al ser una oración condicional incompleta.

2. Separación de las oraciones presentes en el comentario:

Dado que en un comentario se pueden encontrar más de una oración separada por

puntos, éstas se analizan de manera individual, de tal forma que el grafo semántico

resultante no sea tan grande y sea más fácil de manejar.

3. Reconocimiento previo de patrones:

En los comentarios, es normal ver cierto tipo de patrones comunes para referirse

a mismas condiciones. Un ejemplo de esto puede ser la condición anteriormente

citada, "if b is greater than 0".

Estos patrones son previamente reconocidos por el programa para ser sustituidos

por lo que llamamos Placeholders. Son los que "guardan" el sitio a dichos patrones.

El motivo reside en que el Stanford Parser no es capaz de hacer traducciones lite-

rales de muchos de estos patrones, no sabiendo qué son cláusulas como esas. Por

tanto, "greater than 0" se verá encapsulado y guardado antes de realizar el árbol se-

mántico, y posteriormente sustituido en el predicado resultante del Stanford Parser.

6

4. Generación de árboles semánticos para cada oración:

En esta fase, el Stanford Parser genera el árbol semántico correspondiente a cada

oración, quedando éstos almacenados para su posterior procesamiento. Respecto a

la fase anterior, los Placeholders ocupan la misma función semántica que lo que

sustituyen, por lo que no se ve modificada ninguna de las funciones semánticas del

resto de palabras existentes en la oración.

5. Identificación del sujeto:

Tras haber generado el árbol semántico, se extraen de él las funciones de cada

palabra/conjunto de palabras. Lo primero a lo que se procede es a la identificación

del sujeto y a su comparación con el resto del código, para asignarle uno de éstos.

La asignación del sujeto a un código del elemento se lleva a cabo de la siguiente

forma:

Se reúnen todos los elementos del código visibles desde el punto de vista de

la función. Parámetros, métodos, constructores, clases y variables globales.

Se comparan, uno a uno, sujeto y elemento del código, mediante una distancia

de Levensthein (Diferencias entre adiciones, eliminaciones y sustituciones,

tanto de letras como de palabras enteras).

La distancia máxima que se contempla en estos casos es de 2, siendo el valor

de cada adición o eliminación 1, y el valor de eliminar palabras también de

uno. Por ejemplo, la distancia de "aaa" a "aa", sería de una, mientras que la

distancia de "contains the specified vertex" a "containsVertex", sería de 2, ya

que habría que eliminar "the specified" para realizar la asignación.

Al realizar este análisis para un elemento del código, no sólo se tiene en cuenta

la distancia de Levensthein, sino su tipo. Por tanto, se establecen prioridades

entre tipos, siendo la más alta de todas ellas los parámetros, es decir, en el hi-

potético caso de que se tengan dos elementos de código de la misma distancia

Levensthein cuyos tipos son parámetro y método, de estos dos se realizará la

asignación al que sea del tipo parámetro. Se tomó esta decisión en base a la

experiencia de los casos estudiados.

Finalmente, se asigna de forma definitiva al sujeto un elemento del código.

Éste será, en el gran número de casos, la parte izquierda de la condición java

que más adelante se generará.

En caso de que no se halle un sujeto en el árbol semántico, simplemente esa oración

no se traduce, ni produce condición alguna.

7

6. Identificación y traducción del predicado:

Antes de nada, en el predicado se sustituye cada Placeholder por su expresión o

patrón correspondiente.

Acto seguido, se procede a la realización de las siguientes acciones:

Primero, se realiza una separación del predicado. Muchas veces, este contiene

las cláusulas "and" y/o "or", indicando que el predicado está partido, y que han

de analizarse las cláusulas izquierda y derecha por separado, y posteriormente

unirlas con ese "and"/"or".

Tras tener el predicado lo más partido y desmenuzado posible, éste se some-

te a una comparación simple. Esta comparación simple consta de todos los

predicados y patrones que se deducen directamente del texto plano. Es decir,

que si el texto contiene "is positive", la condición directa resultante de aplicar

la comparación simple, será ">0". Estas comparaciones son el resultado de la

experiencia y el análisis de dichos patrones en los @throws analizados previa-

mente durante el desarrollo de la aplicación, y se han ido añadiendo a medida

que se iban descubriendo y estudiando.

Si falla la comparación simple, se pasa a la comparación léxica. Aquí, se deci-

de qué elemento de código asignar al predicado de la misma forma que hacía-

mos en el sujeto: Se realiza la distancia de Levensthein con los elementos del

código y se asignan prioridades según el tipo. Sólo se tienen en cuenta varia-

bles y métodos booleanos que no reciben argumento, debido a la complejidad

de dichas cláusulas en lenguaje natural que son difíciles de traducir.

Al igual que en el sujeto, si se falla la traducción, se deja sin traducir y no se produce

condición.

7. Creación de la condición:

Tras la realización de los pasos previos, tenemos las traducciones del sujeto y del

predicado, no necesitando más que unirlos.

Para el ejemplo del Listing 2 de la sección 3.1, la traducción quedaría de la forma

"args[0]==null || args[1]==null". Los parámetros de entrada de la función siempre

se catalogarán de la forma args[i], siendo i la posición que ocupan en la entrada del

método. También se puede comprobar que se inserta la unión entre ambas cláusulas

debido al "or" presente en el comentario y sustituido con un "||".

Así, finalizaría la labor del traductor de condiciones, y daría paso al generador de

oráculos.

8

3.3. Generador de oráculosEn este punto, los comentarios @throws ya han sido traducidos a expresiones boolea-

nas. Concretamente, el producto obtenido del traductor de condiciones es una tupla del

tipo (método m, excepción e, expresiónBooleana c) para cada comentario que se haya

traducido, en el que se identifica el método junto con la excepción que se ha de lanzar

cuando la condición booleana se cumple.

El generador de oráculos convierte esta salida en un oráculo de test y lo inserta en

cualquier caso de test que invoque m, de tal forma que, antes de ejecutar el caso de test,

se comprueba si la condición c se cumple y, en dicho caso, se lanza la excepción.

ToraDocu emplea AspectJ[9], que se encarga de generar un aspecto para ese caso de

test concreto,en el que modifica el bytecode de dicho caso de test para insertar las compro-

baciones previas mencionadas antes. Si no se ha conseguido generar ninguna condición,

el resultado de ToraDocu sería la creación de un aspecto vacío y que no modificaría el

caso de test.

En caso contrario, se generaría dicho test modificado. A la hora de ejecutar dicho

test, se comprueban las condiciones booleanas antes de lanzar el método. En caso de

cumplirse una, se esperará el lanzamiento de la excepción. Si se lanza, el test pasará. En

caso contrario, pueden suceder dos cosas, (i) que no se halla lanzado la excepción, o que

(ii) se halla lanzado otra excepción diferente, en donde, por tanto, se ha podido dar o un

fallo en el programa, o una inconsistencia entre código y comentario.

3.4. Plataforma de TestExisten dos tipos de test posibles en ToraDocu:

Pruebas unitarias: Estas pruebas comprueban el correcto funcionamiento de las di-

versas clases de ToraDocu, como pueden ser el Matcher, el JavadocExtractor, Th-

rowsTag o DocumentedMethod. Son pruebas que aseguran el manejo de datos y su

transformación.

Pruebas de sistema: Estas pruebas son más complejas. Son tests de regresión que se

miden mediante Precision and Recall. Comprueban que ToraDocu ha creado con-

diciones y, además, que estas son correctas.

Estas pruebas se realizan por sistema, de los cuales se han elegido ciertas clases,

ya sea por su complejidad o por su contenido en cuanto a comentarios complicados

y/o difíciles de procesar. Para ello, ToraDocu, a la salida de cada ejecución, crea un

json con la información de la clase, en donde se guarda toda la información de cada

método analizado en la clase.

9

2 {

3 " s i g n a t u r e " : " mu t a t e ( o rg . apache . commons . math3 . g e n e t i c s . Chromosome o r i g i n a l ) " ,

4 " name " : " m u t a t e " ,

5 " c o n t a i n i n g C l a s s " : {

6 " q u a l i f i e d N a m e " : " o rg . apache . commons . math3 . g e n e t i c s . B i n a r y M u t a t i o n " ,

7 " name " : " B i n a r y M u t a t i o n " ,

8 " i s A r r a y " : f a l s e9 } ,

10 " t a r g e t C l a s s " : " o rg . apache . commons . math3 . g e n e t i c s . B i n a r y M u t a t i o n " ,

11 " i s V a r A r g s " : f a l s e ,

12 " r e t u r n T y p e " : {

13 " q u a l i f i e d N a m e " : " o rg . apache . commons . math3 . g e n e t i c s . Chromosome " ,

14 " name " : " Chromosome " ,

15 " i s A r r a y " : f a l s e16 } ,

17 " p a r a m e t e r s " : [

18 {

19 " t y p e " : {

20 " q u a l i f i e d N a m e " : " o rg . apache . commons . math3 . g e n e t i c s . Chromosome " ,

21 " name " : " Chromosome " ,

22 " i s A r r a y " : f a l s e23 } ,

24 " name " : " o r i g i n a l "

25 }

26 ] ,

27 " th rowsTags " : [

28 {

29 " e x c e p t i o n " : {

30 " q u a l i f i e d N a m e " : " o rg . apache . commons . math3 . e x c e p t i o n .

M a t h I l l e g a l A r g u m e n t E x c e p t i o n " ,

31 " name " : " M a t h I l l e g a l A r g u m e n t E x c e p t i o n " ,

32 " i s A r r a y " : f a l s e33 } ,

34 " codeTags " : [

35 " o r i g i n a l " ,

36 " BinaryChromosome "

37 ] ,

38 " comment " : " i f o r i g i n a l i s n o t an i n s t a n c e o f BinaryChromosome . " ,

39 " k ind " : "THROWS" ,

40 " c o n d i t i o n " : " ( a r g s [ 0 ] i n s t a n c e o f BinaryChromosome ) == f a l s e "

41 }

42 ]

43 }

Listing 3: Ejemplo de JSON generado por ToraDocu

Para la realización de las pruebas, previamente se ha ejecutado ToraDocu para ge-

nerar dichos json. Estos se han almacenado y analizado uno por uno, cambiando el

campo "condition" presente dentro del @throws, que se utilizará para comparar el

generado con el esperado, y calcular así los valores de Precision and Recall.

El valor Precision es el resultante de calcular condiciones correctas entre todas las

condiciones:correctas

correctas+ incorrectas.

10

El valor Recall es el resultante de calcular condiciones generadas correctas entre las

correctas y no correctas (Además de las condiciones que no aparecen):

correctas

correctas+ incorrectas+ faltantes.

4. FUNCIONALIDADES AÑADIDASEn este punto se procede a la explicación del trabajo realizado, en donde se descri-

birán las tareas que se han llevado a cabo para aumentar la funcionalidad de ToraDocu,

y así no sólo limitarse al estudio del @throws, sino al del @param y el @return, pasan-

do de sólo analizar el comportamiento excepcional a extenderlo a las precondiciones y

postcondiciones, haciendo posible el testeo completo de un método.

4.1. Soporte para los Param tagsLos @param son los comentarios de Javadoc que expresan información sobre los pa-

rámetros de la función a la que describen. Suelen ser precondiciones las que vienen ex-

presadas en dichos tags.

Su estructura es la siguiente:

1 ∗ @param nombreDelParamet ro D e s c r i p c i o n D e l P a r a m e t r o .

Listing 4: Estructura de un @param

Gracias al análisis de estos tags, no sólo conseguimos comprobar las precondiciones,

sino que además, a la hora de generar input aleatorio para testear la función, conseguire-

mos reducir el número de fallos, ya que podremos cribar en base a estas precondiciones.

4.1.1. Análisis de patrones

A la hora de traducir los predicados de los comentarios @param, se partía de la base

ya adquirida gracias a los @throws.

Para esta tarea fue necesario la extracción de todos los comentarios @param presentes

en los cinco sistemas que se estudian en ToraDocu: Guava, Apache Commons Collec-

tions4 y Commons Math3, Freecol y Jgrapht.

11

Una vez extraídos todos los comentarios, se fueron analizando uno a uno su viabilidad,

catalogada de 1 a 3:

Catalogado a 1: Comentarios fácilmente traducibles, de patrón claro y que no dan

lugar a equivocación. Un ejemplo sería "@param:fraction Fraction to multiplyby, must not be @code null.", en el que se reconoce claramente la condición "must

not be null".

Catalogado a 2: Comentarios que no serían traducibles por ToraDocu a no ser que

se realizaran grandes cambios en el programa. Ejemplo de este tipo de comentarios

sería "@param:index index of the equation, must be between 0 included andgetNumberOfEquations (excluded)", en donde se extraería la condición descrita

por el intervalo.

Catalogado a 3: Comentarios que ToraDocu no puede traducir, ni a corto ni a largo

plazo, o que carecen de información que utilizar a la hora de generar los tests.

Los ejemplos serían "@param:handler event handler" y "@param:primaryarray containing the current value of the primary state vector", donde se ve

que el primero no da precondición alguna sobre el parámetro, y el segundo tiene

una complejidad muy alta como para ser utilizado en un caso de test.

Tras finalizar el estudio, se comprobó que el 2 % de estos casos eran traducibles sin

tener que modificar mucho ToraDocu, mientras que el segundo caso ocupaba el 10 %,

siendo el 88 % comentarios de gran dificultad o que no proporcionan información útil pa-

ra la creación de tests.

Al realizar las primeras ejecuciones de la herramienta sin modificar (Es decir, con

el mismo traductor de condiciones que tenía el @throws) para saber cómo ToraDocu se

comportaba ante los comentarios del @param, se vio que ToraDocu no era capaz de tra-

ducir el 10 % de los casos catalogados con 1. Es por ello que, al analizar los comentarios,

se tuvo que identificar patrones y causas por las que fallaba el programa.

Se vio que ToraDocu no era capaz de traducir los patrones existentes en @param

debido a que los predicados distaban bastante en cuanto a forma de escribir. Mientras que

en el @throws se veía que el comentario era una fórmula condicional, en el @param era

una fórmula imperativa, en donde se utilizaban diferentes formas verbales (Un ejemplo de

un tipo de patrón, sería el "Must be [condición]", donde, a diferencia de los comentarios

del throws, la forma verbal del verbo "be" es el infinitivo, y no conjugada en singular o

plural.

12

4.1.2. Extracción y traducción de @param

Tras dicha tarea de análisis de patrones, se procedió a realizar la infraestructura y la

modificación de clases que permite manejar estos tags.

Se creó la clase ParamTag. Ésta es la que sostendría la información de los @pa-

ram, tanto nombre del parámetro como sus atributos, así como el comentario y la

condición que posteriormente producirá dicho comentario.

Hubo que modificar el extractor de Javadoc para poder extraer los @param del Java-

doc. Debido a que los tipos que devuelve la API son diferentes de los que nosotros

manejamos, también hubo que realizar extracción de información de dichos tipos

para manejarla de forma correcta. Además, en esta parte se introdujo un tipo de

control específico para comprobar que todos los nombres de los parámetros en los

@param estuvieran presentes en el método, y en caso contrario, reportar un error.

La clase DocumentedMethod se modificó también para almacenar de cada método

los @param correspondientes.

Tras realizar esos cambios en la estructura, se continuó con la parte más importante,

el traductor de condiciones. Como se mencionó previamente, las diferencias entre los dos

tipos de tags que se iban a analizar hacían difícil la reutilización del trabajo ya hecho, por

lo que había que cambiar el modo de análisis en los @param.

Uno de los problemas al que nos enfrentábamos era a la falta de sujeto en muchas

de las oraciones, ya que se daba por hecho que se trataba del parámetro en cuestión. Sin

embargo, el Stanford Parser no podía crear condiciones de oraciones sin sujeto, por lo que

hubo que insertarlo manualmente en cada oración.

Identificando patrones, se comprobó que un gran número eran imperativos, por lo que

seguían la siguiente forma:

(Must/n’t|Could/n’t|Should/n’t) be (condition)

Debido a esto, en la fase previa al traductor, se hubo de insertar en el comentario de

forma manual el parámetro, para que el Stanford Parser lo reconociera.

En este punto, y gracias al previo análisis, pensamos que ya teníamos cubiertos la gran

parte de los casos del @param, por lo que posteriormente se continuó con el testeo de la

parte dedicada a estos tags.

13

4.1.3. Modificación de la plataforma de test y mejoras del análisis

Al concluir las labores de análisis de patrones y extracción y traducción de @param,

se procedió a la selección de clases para trabajar, mantener y mejorar el @param en To-

raDocu. Se escogieron alrededor de 30 clases de entre todos los paquetes seleccionados,

más las clases ya existentes para poder trabajar con el tag.

Dado que el json esperado no contenía el campo ParamTag, se tuvo que realizar una

fusión entre los anteriores y los nuevos jsons generados por ToraDocu, para poder man-

tener el sistema de Precision and Recall que existía con el @throws. También se hizo

cambios en las bases de datos que ToraDocu almacena con los resultados de cada méto-

do, añadiendo los campos correspondientes a los valores del @param.

Tras la correspondiente fusión, se fue por cada json colocando la condición esperada

en cada uno de los campos correspondientes.

Al concluir esto, se obtuvo unos resultados ligeramente negativos, en el que el valor

de Precision en el programa rondaba el 65-70 %, y el valor de Recall un 50 %.

Dados los resultados iniciales, se procedería a la resolución de los problemas existen-

tes con los @param que teníamos en los casos de análisis. Esta tarea a día de hoy sigue

vigente, con unos resultados bastante más favorables, en los que se obtiene un valor del

98 % de Precision y un 88 % en Recall gracias a las tareas de mejora realizadas.

Mejoras:

De la misma forma que se hubo de insertar el sujeto en unas partes, a causa del ca-

rácter restrictivo que deseábamos que tuvieran las precondiciones escritas en el @param,

hubo que eliminar ciertas precondiciones que expresaban posibilidad y no restricción, pe-

ro que ToraDocu interpretaba como restrictivas. Un ejemplo de esto es la cláusula "May

be", que no expresa más que la posibilidad de.

Otro de los problemas que se solucionó fue la falta de sujeto y verbo en la frase.

@param list The list to fill. Not null, not empty

Como se puede ver en el ejemplo, la segunda cláusula de la oración no tiene ni sujeto

ni verbo, dado que ambos están omitidos, y sólo se tiene una frase. Al no poder generar

un árbol semántico satisfactorio, se decidió incluir como patrón especial tanto "not null"

como "not empty", dada la cantidad de comentarios de este tipo. Con este patrón, se

añade tanto sujeto como verbo de forma previa al "not", de tal forma que la frase queda

totalmente aislada de la cláusula anterior y pudiendo así generar el árbol semántico con

el parámetro como sujeto y el verbo "be" conjugado.

14

4.2. Soporte para los Return tagsLos @return son los comentarios de Javadoc que expresan información sobre el valor

de salida de la función en cuestión. Suelen ser postondiciones las que vienen expresadas

en dichos tags.

La estructura más común encontrada es la siguiente:

1 ∗ @return v a l o r D e R e t o r n o s i c o n d i c i o n A C u m p l i r P a r a E l l o c a s o C o n t r a r i o

v a l o r D e R e t o r n o E n C a s o C o n t r a r i o .

Listing 5: Estructura de un @return

Gracias al análisis de estos tags, conseguimos comprobar el valor de salida de la fun-

ción. La importancia del análisis de estos tags viene dada por la gran ventaja que ésto

supone: Poder ser capaces de testear un método de forma completa sin necesidad de pro-

gramar el test por nosotros mismos.

Así pues, y gracias a ésto, ToraDocu cumple su objetivo.

4.2.1. Análisis de patrones

A la hora de traducir los predicados de los comentarios @return, se partía de la base

ya adquirida gracias a los @throws y parte de los @param.

Para esta tarea fue necesario la extracción de todos los comentarios @return presentes

en los cinco sistemas que se estudian en ToraDocu.

15

Una vez extraídos todos los comentarios, al igual que en @param, se fueron analizan-

do uno a uno su viabilidad, catalogada de 1 a 3:

Catalogado a 1: Comentarios fácilmente traducibles, de patrón claro y que no dan

lugar a equivocación. Un ejemplo sería "@return true.", en el que se reconoce

claramente que la función siempre retornará verdadero. Otro ejemplo de estos casos

podría ser "@return true if a is less than 0; otherwise false, en donde se ve que

el valor de retorno es verdadero si se cumple la condición a<0, y falso en el caso

contrario.

Catalogado a 2: Comentarios que no serían traducibles por ToraDocu a no ser que

se realizaran grandes cambios en el programa. Ejemplo de este tipo de comentarios

sería "@return the first prime number of the array", en donde se entendería

que el valor de salida sería el primer número primo del array, teniendo que recorrer

todos los componentes del array hasta encontrar el primer primo.

Catalogado a 3: Comentarios que ToraDocu no puede traducir, ni a corto ni a largo

plazo, o que carecen de información que utilizar a la hora de generar los tests. Los

ejemplos serían "@return a list" y "@return an iterator positioned in the 5thposition if the count is greater than 6 in runtime.", donde se ve que el primero no

da postcondición alguna, y el segundo tiene una complejidad muy alta como para

ser utilizado en un caso de test.

Tras finalizar el estudio, se comprobó que el 0,5 % de estos casos eran traducibles

sin tener que modificar mucho ToraDocu, mientras que el segundo caso ocupaba el 5 %,

siendo el 94,5 % comentarios de gran dificultad o que no proporcionan información útil

para la creación de tests.

Al realizar las primeras ejecuciones de la herramienta sin modificar (Es decir, con

el mismo traductor de condiciones que tenía el @throws y con las modificaciones per-

tinentes realizadas en el @param) para saber cómo ToraDocu se comportaba ante los

comentarios del @return, se vio que ToraDocu no era capaz de traducir siquiera el 5 % de

los casos catalogados con 1. Al igual que con el @param, se procedió a la revisión de los

patrones y formas características del @return.

Se vio que ToraDocu no era capaz de traducir los patrones existentes en @return de-

bido a que la estructura era la más compleja de todas. Aun siendo similar al @throws,

se daba el caso de que los predicados aumentaban en complejidad mucho más que en los

anteriores tags.

Se identificó un patrón común a la gran mayoría de comentarios, y es el que se mues-

tra como ejemplo en el Listing 5. Los comentarios ahora tenían varias partes de la frase

que ser analizadas. Antes, todo el comentario era dado al Stanford Parser para que pudie-

ra generarnos los árboles semánticos. Ahora, había que separar la frase en tres pedazos

diferentes, para poder analizarlos de forma independiente.

16

Valor de Retorno: Es la característica que cumple el valor de retorno en caso afir-

mativo.

Condición a cumplir para el primer valor de retorno: Condición que ha de cumplirse

para que se pueda aplicar la característica indicada en el primer valor de retorno.

Caso contrario: Campo que identifica la negación de la primera cláusula,

Valor de Retorno en caso contrario: Característica del valor de retorno que se da al

no cumplirse la primera condición.

4.2.2. Extracción y traducción de @return

Tras dicha tarea de análisis de patrones, se procedió a realizar la infraestructura y la

modificación de clases que permite manejar estos tags.

Se creó la clase ReturnTag. Ésta es la que sostendría la información de los @re-

turn, tanto nombre del parámetro como sus atributos, así como el comentario y la

condición que posteriormente producirá dicho comentario.

Hubo que modificar el extractor de Javadoc para poder extraer los @return del

Javadoc. Esta parte fue más fácil de manejar y mucho menos liosa, ya que el return

carece de información específica tal como parámetros o excepciones a lanzar: Es

un comentario en bruto, y de ahí su dificultad para ser analizado.

La clase DocumentedMethod se modificó también para almacenar de cada método

los @return correspondientes y las condiciones que estos generarían.

Como en el anterior tipo de tag, se procedió a los cambios más importantes y compli-

cados en el programa, los cambios en el traductor de condiciones.

Para este caso especial, se separó el return en tres partes. La primera de ellas sería la

correspondiente al valor de retorno descrito anteriormente. El segundo sería la primera

condición de retorno. Y finalmente, la tercera parte sería la correspondiente al caso nega-

tivo, la tercera y cuarta partes juntas.

En el análisis de la primera, se contempló que los valores de retorno sólo podrían ocu-

par los valores de "true" o "false". Por tanto, se hizo la asumpción de que estos valores

sólo tendrían esas dos posibilidades, decidiendo así en una primera instancia limitar To-

raDocu a funciones booleanas, por definición.

La segunda parte se conseguía tras partir la frase por el primer " if " que se encontraba

en esta, separando el valor de retorno y la condición. La condición se traduce de la misma

forma que se traduce en el @throws.

17

Finalmente, la tercera parte que aparecía de forma opcional, se obtenía partiendo la

oración gracias a palabras claves como "otherwise", o por la aparición de ";" en la oración,

y su análisis es igual que la segunda parte.

Al concluir la traducción, todas las condiciones se juntan en una sola, dando lugar a

un tipo de condición característico del @return:

1 c o n d i t i o n : " Cond ic ion ? R e s u l t a d o S i C o n d i c i o n T r u e [ : R e s u l t a d o S i C o n d i c i o n F a l s e ]

Listing 6: Estructura de la condición en el @return

La condición es la parte Java que se evaluará a verdadero o falso, y en base a ese valor,

se determinará una característica para el valor de return.

4.2.3. Modificación de la plataforma de test y mejoras

Al concluir las labores de análisis de patrones y extracción y traducción de @return,

al igual que en el param, se procedió a la selección de clases para trabajar, mantener y

mejorar el @return en ToraDocu. Se escogieron alrededor de 20 clases de entre todos los

paquetes seleccionados, más las clases ya existentes (del @throws y del @param) para

poder trabajar con el tag.

Dado que el json esperado no contenía el campo ReturnTag, de la misma forma que

se realizó con el @param, se tuvo que realizar una fusión entre los anteriores y los nuevos

jsons generados por ToraDocu, para poder mantener el sistema de Precision and Recall.

También se hizo cambios en las bases de datos que ToraDocu almacena con los resultados

de cada método, añadiendo los campos correspondientes a los valores del @return.

Tras la correspondiente fusión, se fue por cada json colocando la condición esperada

en cada uno de los campos correspondientes.

Al concluir esto, se obtuvo unos resultados nefastos, en el que el valor de Precision en

el programa rondaba el 50 %, y el valor de Recall un 5 %.

Debidos a estos malos resultados, se procedió a realizar mejoras en el análisis.

Una de ellas fue la contemplación de la existencia de sólo una característica del valor

de return, sin necesidad de que éste fuera verdadero o falso, es decir, que se cumple siem-

pre. Estas son las condiciones del tipo "@return: a sorted bag", en donde se determina

que directamente la característica que se produce sería la de "result.isSorted()".

Otra de las mejoras vino producida por los fallos de ToraDocu a la hora de reconocer

el sujeto. Para ello se implementó un POSTagger. La función de este módulo es la de

catalogar, sin necesidad de pasar por el Stanford Parser, el sujeto.

18

Esto no funciona con todos los comentarios @return debido a que se fundamenta en

la existencia de @code tags rodeando al elemento del código al que se refiere el @return

como se puede ver a continuación:

1 @return a s o r t e d bag i f {@code e l e m e n t } does n o t c o n t a i n s any n u l l v a l u e .

Listing 7: Ejemplo de @code en @return

Con esta técnica lo que se consigue es que el Stanford Parser se adapte a nuestro tag

personalizado, traduciendo directamente el predicado sobre él.

5. EVALUACIÓN Y TESTEn esta sección se evaluará y medirán los resultados de los test arrojados por ToraDocu

antes y después de las mejoras.

5.1. Estado previoComo se ha explicado anteriormente, ToraDocu antes de este TFG, sólo manejaba los

comentarios del tipo @throws.

Los resultados de los test fueron de una Precision del 82 % y un Recall del 52 %, con-

templando un total de 289 métodos en estudio.

Los predicados comprendidos no iban más allá de lo simple, contemplando condicio-

nes sencillas como "is null", "is > than" o "is true", así como el reconocimiento de algunas

funciones como "isEmpty()".

5.2. Estado actualA día de hoy, y gracias a este TFG, ToraDocu se ha expandido a los @param y a los

@return.

Los resultados de los test fueron de una Precision del 95 % y de un Recall del 76 %,

en el caso global, contemplando 430 métodos en total, y en concreto, los del @throws

mejoraron hasta una Precision del 95 % y un Recall del 75 %.

Los otros dos tags registraron unos resultados finales de una Precision del 98 % y un

Recall del 88 % para el @param, y un 84 % y 54 % para el @return, respectivamente.

5.3. Caso real: Uso de ToraDocuA pesar de ser un trabajo de investigación y estar aún en desarrollo, a continuación se

muestra un estudio realizado con ToraDocu.

19

En él se ha realizado la ejecución de ToraDocu sobre todas las clases de los sistemas

Commons Collections4[10], Commons Math3[11] y PlumeLib[12]

Figura 2: Condiciones del @param en Commons Collections

Figura 3: Condiciones del @throws en Commons Collections

Como se puede comprobar en los gráficos de @throws y @param de Collections [Fi-

guras 1 y 2], en más de la mitad de predicados se produce al menos una condición. Ade-

más, se puede observar que el porcentaje de reconocimiento de condiciones tanto en los

@param como en los @throws se obtiene el mismo porcentaje, debido a que existe una

fuerte correlación entre dichos tags, dado que en la gran mayoría de los casos una viola-

ción de las precondiciones provoca una excepción.

20

Figura 4: Condiciones del @return en Commons Collections

En cambio, en el @return de Collections [Figura 3] vemos cómo ToraDocu sólo pro-

porciona condiciones de aproximadamente un 15 % de estos tags, debido a su estado

menos avanzado y la complejidad de dichos tags.

Figura 5: Condiciones del @param en Commons Math3

Figura 6: Condiciones del @throws en Commons Math3

21

De la misma forma que se observó esa estrecha correlación en Collections, en @th-

rows y @param de Math3 también se puede observar esta propiedad [Figuras 4 y 5]

Figura 7: Condiciones del @return en Commons Math3

En Math3, notamos cómo el ratio de @return que produce condición aumenta [Figura

6], probablemente debido a la cantidad de predicados aritméticos que contiene y que To-

raDocu es capaz de traducir.

22

Figura 8: Condiciones del @param en Plume Lib

Figura 9: Condiciones del @throws en Plume Lib

Figura 10: Condiciones del @return en Plume Lib

Y para finalizar vemos que, al igual que en los dos sistemas anteriores, en Plume Lib

también existe esa estrecha correlación entre @param y @throws [Figura 7 y 8], y que el

ratio de @return también aumenta respecto a los dos anteriores [Figura 9].

23

6. TRABAJO FUTUROCaso real de ToraDocu: Control sobre la programación del desarrollador.

Como se ha visto en el punto 5.3, se pueden realizar con ToraDocu controles sobre

la calidad de la documentación de sistemas y/o clases. Esto aplicado a una em-

presa, serviría para realizar cribas entre los desarrolladores que no documenten su

código con X calidad, siendo la calidad el porcentaje de condiciones que debería

de producir los tags del JavaDoc de la clase que se programe, y pudiendo avisar al

desarrollador de dichos fallos para que los pueda corregir, aumentando así la calidad

de la documentación.

Analizador semántico

En el futuro, se plantea además del uso del analizador sintáctico que ahora mismo

se tiene, la implementación de un analizador semántico, que nos permitiría eliminar

la distancia de Levensthein para relacionar elementos del código con los sujetos/-

predicados para sustituirla con sinónimos entre palabras. Es decir, que ya no sólo

se compararía por distancia de Levensthein, sino que se haría uso de un diccionario

de sinónimos para poder relacionar ambos elementos. Ésto ayudaría a la identifica-

ción del sujeto en caso de que el desarrollador haya utilizado un nombre distinto al

elemento del código en la documentación.

Plataforma online de integración continua

Como se ha visto anteriormente, ToraDocu puede ser una herramienta perfecta de

control de documentación. Además de ésto, también cabe la posibilidad de hacer

que ToraDocu, con un funcionamiento similar a Travis CI[13], sirva de herramienta

de integración continua, generando los tests de las clases que se decidan subir a

dicha plataforma y testeándolas online, sin necesidad de ejecutar ToraDocu en tu

ordenador.

Machine learning

Aprendiendo de los casos buenos y de los casos malos, ToraDocu podría aumentar

su eficacia si se utilizara esta técnica, en donde el programa podría aprender qué

elementos comunes tienen ciertos tipos de condiciones, y aumentando así el ratio

de documentación que ToraDocu podría traducir a condiciones.

24

7. CONCLUSIONESSe ha de resaltar que este trabajo ha sido en su mayor parte de investigación. Es por

ello que muchas de las dudas y problemas que han surgido no han podido más que intentar

esclarecer y resolver de la mejor forma posible, con mucha prueba y error.

Debido al hecho anterior, se resalta la necesidad de tener una mente abierta y mucha

creatividad a la hora de desarrollar el software para que éste funcione como es necesario.

Gracias a este trabajo, he comprendido la necesidad de la documentación y el gran

potencial que tiene en este campo, así como lo útil que resultan algunas herramientas

NPL como el Stanford Parser. He podido probar de primera mano lo que es el estar en un

proyecto de investigación y he aprendido cómo se manejan las cosas en este entorno.

Finalmente decir que, a pesar de que los resultados del proyecto aún no son perfectos

y aún queda mucho por mejorar en ToraDocu, el proyecto apunta alto, no sólo como he-

rramienta de testing, sino como herramienta de traducción de lenguaje natural a lenguaje

de programación, y que sus trabajos futuros, aunque se hayan citado anteriormente sólo

algunos, éstos son cuasi infinitos.

25

REFERENCIAS[1] C. Saran, “Application testing costs set to rise to 40 of it budget”, 2015. dirección:

http://www.computerweekly.com/news/4500253336/Application-testing-costs-set-to-rise-to-40-of-IT-budget.

[2] E. G. y Kent Beck, “Junit”, 2017. dirección: http://junit.org/junit4/.

[3] G. Fraser y A. Arcuri, “Evosuite: automatic test suite generation for object-oriented

software”, 2011. dirección: http://www.evosuite.org/.

[4] C. Pacheco y M. D. Ernst, “Randoop: feedback-directed random testing for java”.

dirección: http://doi.acm.org/10.1145/1297846.1297902.

[5] S. H. Tan, D. Marinov, L. Tan y G. T. Leavens, “@tcomment: testing javadoc

comments to detect comment-code inconsistencies”, en In Proc. 5th ICST, 2012,

págs. 260-269.

[6] A. Goffi, A. Gorla, M. D. Ernst y M. Pezzè, “Automatic generation of oracles for

exceptional behaviors”, 2016.

[7] “Javadoc api”. dirección: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html.

[8] “Stanford parser library”. dirección: https://nlp.stanford.edu/software/lex-parser.shtml.

[9] “Aspectj”. dirección: https://eclipse.org/aspectj/.

[10] “Commons collection4”. dirección: https : / / commons . apache . org /proper/commons-collections/.

[11] “Commons math3”. dirección: https://commons.apache.org/proper/commons-math/.

[12] “Plume lib”. dirección: https://github.com/mernst/plume-lib.

[13] “Travis ci”. dirección: https://travis-ci.org/.

26

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Wed Jun 07 14:18:02 CEST 2017

Emisor delCertificado

EMAILADDRESS=camanager@fi.upm.es, CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)