Validación de módulos para Poliformat

UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA “Validación de módulos de Poliformat” PROYECTO FINAL DE CARRERA CÓDIGO: DISCA-123 AUTOR: Vicente Ramón Orts Orts DIRECTOR: Dr. Lenin Guillermo Lemus Zúñiga Profesor Titular de Universidad Universidad Politécnica de Valencia Septiembre 2012 Vicente Ramón Orts Orts 2 Vicente Ramón Orts Orts 3 1. Introducción. ........................................................................................................ 7 1.1. Contexto ........................................................................................................................................................... 7 1.2. Motivación del proyecto. ........................................................................................................................... 7 1.3. Metodología de trabajo. ............................................................................................................................. 8 2. Objetivo. .............................................................................................................. 8 3. Tecnologías Utilizadas. .......................................................................................... 9 3.1. Java. ................................................................................................................................................................... 9 3.2. Maven. ............................................................................................................................................................... 9 3.3. Subversion. .................................................................................................................................................... 10 3.4. Apache Tomcat. ........................................................................................................................................... 10 3.5. MySQL. ........................................................................................................................................................... 10 3.6. Eclipse. ............................................................................................................................................................ 10 3.7. Wicket. ............................................................................................................................................................ 11 4. Instalación Sakai 2.10-SNAPSHOT. ...................................................................... 13 4.1. Instalación Java. .......................................................................................................................................... 13 4.2. Instalación MySQL 5.1. ............................................................................................................................. 16 4.3. Instalación Maven 2.2.X. .......................................................................................................................... 18 4.4. Instalación Subversion. ............................................................................................................................ 19 4.5. Instalación Apache Tomcat 7.0.27. .................................................................................................... 20 4.6. Instalación MySQL connector/J. ........................................................................................................... 22 4.7. Descargar Sakai 2.10-SNAPSHOT. ....................................................................................................... 22 4.8. Configurar Sakai 2.10-SNAPSHOT. ...................................................................................................... 22 4.9. Configurar Maven. ...................................................................................................................................... 24 4.10. Despliegue Sakai. ..................................................................................................................................... 24 4.11. Errores o problemas típicos. ............................................................................................................... 26 4.11.1. Explicación del POM. .............................................................................................................................. 26 4.11.2. Solución de errores. ................................................................................................................................ 28 4.12. Iniciar Tomcat. .......................................................................................................................................... 30 4.13. Instalación Eclipse. ................................................................................................................................. 32 4.13.1. Instalación plugin Subclipse. ............................................................................................................. 35 4.13.2. Instalación plugin Maven. ................................................................................................................... 38 4.14. Integrar Sakai en Eclipse. ..................................................................................................................... 39 5. Construcción aplicación Wicket en Sakai. ............................................................ 43 5.1. Casos de uso. ................................................................................................................................................. 44 5.3. Arquetipo. ...................................................................................................................................................... 46 5.4. Despliegue de la aplicación. ................................................................................................................... 47 6. Pruebas de la aplicación. ..................................................................................... 49 6.1. Estrategias de prueba. .............................................................................................................................. 49 6.1.1. Pruebas unitarias. ...................................................................................................................................... 49 6.1.2. Pruebas de integración. .......................................................................................................................... 50 6.1.3. Pruebas de validación. ............................................................................................................................. 50 6.1.4. Pruebas de aceptación. ............................................................................................................................ 51 6.2. Pruebas unitarias con JUnit. ................................................................................................................... 51 6.2.1 JUnit ................................................................................................................................................................... 51 6.2.2. Instalación de JUnit. .................................................................................................................................. 52 6.2.3. Elementos de las pruebas con JUnit................................................................................................... 52 6.2.4. Creación de una clase de pruebas para eShop. ............................................................................ 54 6.3. Estándar de pruebas. ................................................................................................................................ 57 6.3.1. IEEE 829 ......................................................................................................................................................... 57 Vicente Ramón Orts Orts 4 6.3.2 ISO 9126 .......................................................................................................................................................... 58 6.4. Informe de pruebas. .................................................................................................................................. 59 7. Conclusiones. .................................................................................................. 61 8. Bibliografía. .................................................................................................... 63 Figura 1. Logo Java. ............................................................................................................................. 9 Figura 2. Logo Maven. ........................................................................................................................ 9 Figura 3. Logo Subversion. ............................................................................................................ 10 Figura 4. Logo Apache. .................................................................................................................... 10 Figura 5. Logo MySQL. ..................................................................................................................... 10 Figura 6. Logo Eclipse. .................................................................................................................... 10 Figura 7. Logo Apache Wicket. ..................................................................................................... 11 Figura 8. Imagen que ilustra la configuración por defecto de la instalación de Java y la ruta. ....................................................................................................................................... 13 Figura 9. Imagen del resultado de la ejecución de java –version. .................................. 13 Figura 10. Propiedades del sistema. .......................................................................................... 14 Figura 11. Variables de entorno. ................................................................................................. 15 Figura 12. Instalación MySQL, selección de configuración. .............................................. 16 Figura 13. Instalación MySQL, instalación de servicio, puesta en marcha automática e inclusión en el Path. ............................................................................................................ 16 Figura 14. Instalación MySQL, creación de usuario root. .................................................. 17 Figura 15. Contenido del Path con la varibale de entorno M2_HOME. ........................ 18 Figura 16. Resultado instrucción mvn -version. ................................................................... 18 Figura 17. Contenido del Path con la variable de entorno SUBVERSION_HOME. .... 19 Figura 18. Resultado comando svn --version......................................................................... 19 Figura 19. Contenido del Path con la variable de entorno CATALINA_HOME. ......... 20 Figura 20. Imagen de la modificación del archivo server.xml. ........................................ 21 Figura 21. Resultado de la ejecución del comando mvn clean install. ......................... 25 Figura 22. Resultado del despliegue del Sakai. ..................................................................... 25 Figura 23. Error in opening zip file. ........................................................................................... 28 Figura 24. Error required artifact is missing. ........................................................................ 29 Figura 25. Resultado de poner en marcha el servidor Tomcat. ...................................... 30 Figura 26. Pagina principal del Sakai. ....................................................................................... 31 Figura 27. Detalle de la pagina principal del Sakai, donde se ve la versión del Sakai y el sistema operativo donde esta instalado. ................................................................ 31 Figura 28. Pagina de inicio posterior a la autentificación del Administrador. .......... 32 Figura 29. Imagen de la carga del programa Eclipse. ......................................................... 33 Figura 30. Preferencias del Eclipse. ........................................................................................... 34 Figura 31. Edición del JRE. ............................................................................................................ 35 Figura 32. Pantalla de instalación de nuevos componentes. ........................................... 36 Figura 33. Pantalla con formulario que sirve para añadir nuevos repositorios de plugins. ........................................................................................................................................ 36 Figura 34. Paquetes pertenecientes a la instalación de Subeclipse. ............................. 37 Figura 35. Condiciones instalación Subclipse. ....................................................................... 37 Figura 36. Petición de reinicio de Eclipse. ............................................................................... 38 Figura 37. Paquetes pertenecientes a la instalación de Maven2Eclipse. .................... 38 Vicente Ramón Orts Orts 5 Figura 38. Selección del directorio de trabajo. ...................................................................... 39 Figura 39. Preferencias de Eclipse, sección Classpath Variables. .................................. 40 Figura 40. Selección de tipo de archivo a importar. ............................................................ 40 Figura 41. Proyectos seleccionados para importar al Eclipse. ........................................ 41 Figura 42. Casos de Uso. ................................................................................................................. 44 Figura 43. Herencia entre excepciones. ................................................................................... 44 Figura 44. Diagrama de clases de la aplicación. .................................................................... 45 Figura 45. Diagrama de clases entre las paginas que se visualizan en la aplicación. ........................................................................................................................................................ 45 Figura 46. Resultado del despliegue de la aplicación. ........................................................ 47 Figura 47. Visualización del mercury site. .............................................................................. 48 Figura 48. Interacciones entre fases y pruebas. .................................................................... 49 Figura 49. Ejemplo de matriz de trazabilidad. ...................................................................... 51 Figura 50. Ventana selección creación nuevos archivos. ................................................. 54 Figura 51. Creación JUnit Test Case. .......................................................................................... 55 Figura 52. Resultado UserTest. .................................................................................................... 57 Figura 53. Ejemplo Informe de Pruebas. ................................................................................. 60 Código 1. Contenido de las variables de entorno JAVA_HOME y JAVA_OPTS. ........... 14 Código 2. Modificación del archivo my.ini............................................................................... 17 Código 3. Instrucción inicio MySQL ........................................................................................... 17 Código 4. Instrucción creación Base de Datos Sakai. .......................................................... 18 Código 5. Contenido variables de entorno MAVEN_OPTS, M2_HOME y Path. .......... 18 Código 6. Contenido de variables de entorno SUBVERSION_HOME y Path. .............. 19 Código 7. Contenido de las variables de entorno CATALAINA_HOME y Path. .......... 20 Código 8. Modificación del archivo server.xml. ..................................................................... 20 Código 9. Contenido del archivo setenv.bat............................................................................ 21 Código 10. Contenido de la variable common.loader en el archivo catalina.properties. ................................................................................................................. 21 Código 11. Contenido de la variable shared.loader en el archivo catalina.properties. ........................................................................................................................................................ 21 Código 12. Contenido de la variable server.loader en el archivo catalina.properties. ........................................................................................................................................................ 22 Código 13. Comando necesario para descarga el Sakai. .................................................... 22 Código 14. Líneas que se deben comentar en el archivo default.sakai.properties. . 23 Código 15. Líneas que se deben descomentar en el archivo default.sakai.properties ........................................................................................................................................................ 23 Código 16. Contenido recomendado archivo setting.xml. ................................................. 24 Código 17. Contenido de un archivo de tipo POM de ejemplo. ....................................... 27 Código 18. Comando necesario para descargar dependencia del repositorio de Maven. .......................................................................................................................................... 30 Código 19. Opciones de memoria de Eclipse. ......................................................................... 33 Código 20. Opciones de inicio de Eclipse. ................................................................................ 33 Código 21. Instrucciones para adaptar la aplicación a Eclipse. ...................................... 39 Código 22. Contenido archivo ejemplo.html .......................................................................... 43 Código 23. Contenido archivo ejemplo.java ........................................................................... 43 Código 24. Arquetipo para la construcción de la aplicación de Sakai. ......................... 46 Código 25. Dependencia Maven del JUnit ................................................................................ 52 Vicente Ramón Orts Orts 6 Código 26. Líneas necesarias para la creación de la dependencia JUnit en los módulos. ...................................................................................................................................... 52 Código 27. Clase de pruebas VectorTest. ................................................................................. 53 Código 28. Método testCapacidad. ............................................................................................. 53 Código 29. Método testClonar. ..................................................................................................... 54 Código 30. Cuerpo Principal de la clase UserTest. ............................................................... 55 Código 31. Código de los métodos test. .................................................................................... 56 Vicente Ramón Orts Orts 7 1. Introducción. 1.1. Contexto Sakai en su propia pagina se define como, A community of educators collaborating To create open software that advances teaching, learning and research, que traduciéndolo a nuestro idioma quiere decir: Una comunidad de educadores que colaboran para crear software de código abierto para la enseñanza avanzada, el aprendizaje y la investigación. Sakai es una comunidad donde abarca muchos tipos de profesionales que colaborar conjuntamente para definir las necesidades académicas de los usuarios, creando herramientas de software, compartiendo las mejores practicas, conocimientos y recursos para el apoyo de este objetivo. La Comunidad Sakai desarrolla software de código abierto para apoyar la docencia y colabora en dos tipos de proyectos el Sakai CLE, colaboración y entorno de aprendizaje, y Sakai OAE, Entorno académico abierto. Sakai está apoyado por una fundación que facilita el éxito de la comunidad y su software. La Fundación Sakai no dicta la dirección de la comunidad. Desempeña un papel de apoyo en la creación de la infraestructura de colaboración, lleva el proceso de administración de versiones/publicaciones, facilita la comunicación y la coordinación de toda la comunidad. 1.2. Motivación del proyecto. Sakai es un sistema robusto que da soporte a 4 millones usuarios educativos para potenciar la enseñanza cooperativa, el aprendizaje y la investigación. Sakai es utilizado por grandes instituciones con multitud de usuarios, que pertenecen a la fundación Sakai para la gestión de este. Cuenta con mas de 100 instituciones y las mas importantes que pertenecen a la fundación son las siguientes:  Metropolitan autonom University  Indiana University  University of Michigan  Yale University  Stanford University  Universidad Politécnica de Valencia  Universidad del Valle de Guatemala  Universidad Complutense de Madrid  Universidad Católica San Antonio de Murcia  Universidad de Murcia  Universidad Pública de Navarra Sakai tiene la problemática que esta creado para entornos muy grandes, por ejemplo la aplicación de Poliformat basada en el entorno Sakai que tiene desarrollada la Universidad Politécnica de Valencia. La universidad tiene 36.187 alumnos matriculados que son usuarios del Poliformat y 2.843 usuarios mas entre profesores e investigadores, en total 39.030 usuarios que deben ser gestionados al mismo tiempo. Cuando se intenta implantar el Sakai en instalaciones mas Vicente Ramón Orts Orts 8 reducidas y con menos recursos resulta complicado ya que hay poco material y de haberlo esta desactualizado. Para poder comenzar a implantar y desarrollar algunas de las funcionalidades de Sakai se necesitan altos conocimientos técnicos, ya que se trata de un software de código abierto. Por el contrario para ser usuario de la herramienta Sakai no se necesitan muchos conocimientos técnicos ya que la herramienta una vez instalada y puesta en marcha se comporta como una pagina web con módulos que se van agregando y quitando para ofrecer nuevas funcionalidades. Por todos estos problemas se encuentran motivos para desarrollar un proyecto que proporcione una guía para el desarrollo de aplicación para la herramienta Sakai. 1.3. Metodología de trabajo. 1. Búsqueda de información relaciona con Sakai, como funciona, que entidades participan, herramientas utilizadas, lenguajes utilizados, manuales,… 2. Instalación de herramientas necesarias para la puesta en marcha de Sakai. 3. Instalación, prueba y solución de problemas de la distribución reducida de Sakai Café. 4. Instalación completa de la ultima distribución de Sakai. 5. Análisis y desarrollo de una aplicación en Wicket para Sakai. 6. Búsqueda de información sobre pruebas para software: 7. Creación de Pruebas unitarias con JUnit. 8. Pruebas del correcto funcionamiento de aplicación. 2. Objetivo. El objetivo principal del proyecto es: “Conocer el funcionamiento del Sakai e implementar una aplicación en el entorno.” Con esta iniciativa se pretende crear una base para futuros proyectos de desarrollo en Sakai, que proporcione una guía para desarrolladores que quieran iniciarse en el entorno de Sakai. La aplicación desarrollada en este proyecto puede ser modificada para su utilización en el entorno de Poliformat para la inscripción en cursos o seminarios. Vicente Ramón Orts Orts 9 3. Tecnologías Utilizadas. Para poder realizar una instalación completa y funcional de Sakai se necesitan todas estas tecnologías. Cada una de ellas proporciona al desarrollador una funcionalidad que facilitara y acelerara el desarrollo de la aplicación. 3.1. Java. Java es un lenguaje de programación orientado a objetos, desarrollado por Sun Microsystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de punteros o memoria. 3.2. Maven. Es una herramienta de software para la gestión y construcción de proyectos Java creada por Jason van Zyl, de Sonatype, en 2002. Tiene un modelo de configuración de construcción simple, basado en un formato XML. Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Una característica clave de Maven es que está listo para usarse en red. El motor incluido en su núcleo puede dinámicamente descargar plugins de un repositorio, el mismo repositorio que provee acceso a muchas versiones de diferentes proyectos Open Source en Java, de Apache y otras organizaciones y desarrolladores. Este repositorio y su sucesor reorganizado, el repositorio Maven 2, pugnan por ser el mecanismo de facto de distribución de aplicaciones en Java, pero su adopción ha sido muy lenta. Maven provee soporte no sólo para obtener archivos de su repositorio, sino también para subir artefactos al repositorio al final de la construcción de la aplicación, dejándola al acceso de todos los usuarios. Una caché local de artefactos actúa como la primera fuente para sincronizar la salida de los proyectos a un sistema local. Maven está construido usando una arquitectura basada en plugins que permite que utilice cualquier aplicación controlable a través de la entrada estándar. En teoría, esto podría permitir a cualquiera escribir plugins para su interfaz con herramientas como compiladores, herramientas de pruebas unitarias, etcétera, para cualquier otro lenguaje. Figura 1. Logo Java. Figura 2. Logo Maven. Vicente Ramón Orts Orts 16 4.2. Instalación MySQL 5.1. La versión necesaria del MySQL Community Server se puede bajar del siguiente enlace: http://dev.mysql.com/downloads/mysql/ Siguiendo las pautas anteriores hay que instalar en nuestra carpeta en la ruta C:\opt\mysql, hay que seleccionar las siguientes opciones en la instalación:  La instalación estándar. Figura 12. Instalación MySQL, selección de configuración.  Instalar el servicio de Windows | Inicio automático | Incluir el directorio en el path. Figura 13. Instalación MySQL, instalación de servicio, puesta en marcha automática e inclusión en el Path. Vicente Ramón Orts Orts 17  No usar una cuenta anónima y crear la contraseña del usuario root con este valor mysqlpwd1. Figura 14. Instalación MySQL, creación de usuario root. Hay que modificar el archivo de configuración del MySQL llamado my.ini que se encuentra en c:\opt\mysql\ añadiendo las siguientes líneas en la sección [mysqld]: Código 2. Modificación del archivo my.ini. A continuación deberíamos probar que la versión instalada del MySQL funciona correctamente con el comando “mysql –version”, debemos iniciar el programa con el usuario y contraseña creados anteriormente que son root con la contraseña pmysqlpwd1 con el siguiente comando. Código 3. Instrucción inicio MySQL Posteriormente de autentificarnos crearemos el esquema necesario para que funcione el Sakai correctamente, con el usuario Sakai y contraseña ironchef, con el siguiente comando. default-storage-engine = InnoDB innodb_file_per_table character-set-server=utf8 collation-server=utf8_general_ci lower_case_table_names = 1 mysql -uroot -pmysqlpwd1 Vicente Ramón Orts Orts 18 Código 4. Instrucción creación Base de Datos Sakai. 4.3. Instalación Maven 2.2.X. En este enlace se encuentra la versión necesaria de Maven, mínimo la 2.2.1. http://maven.apache.org/download.html Después de bajar la versión correcta hay descomprimirla en la carpeta opt, seguidamente se crea la variable de entorno m2_home con la ruta de la instalación de Maven. A continuación se añade la nueva variable al path como se ha explicado anteriormente. También es necesario crear la variable maven_opts. Código 5. Contenido variables de entorno MAVEN_OPTS, M2_HOME y Path. Figura 15. Contenido del Path con la varibale de entorno M2_HOME. Para comprobar que funciona se puede probar mediante el comando “mvn – version”. Figura 16. Resultado instrucción mvn -version. create database sakai default character set utf8; grant all privileges on sakai.* to 'sakai'@'localhost' identified by 'ironchef'; flush privileges; quit MAVEN_OPTS=-Xms128m -Xmx796m -XX:PermSize=64m -XX:MaxPermSize=172m M2_HOME=c:\opt\maven-2.2.1 Path= …;%M2_HOME%\bin;… Vicente Ramón Orts Orts 19 4.4. Instalación Subversion. En el siguiente enlace se encuentra el paquete necesario para la instalación http://subversion.apache.org/packages.html#windows también recomiendo la instalación de in cliente visual para poder gestionar nuestro software desde una interfaz grafica. Para instalación hay que crear una nueva carpeta en opt y descomprimir el paquete que nos hemos bajado anteriormente. Igual como hemos hecho anteriormente hay que agregar este nuevo programa al path, siguiendo la misma política crearemos una nueva variable de entorno llamada subversión_home. Código 6. Contenido de variables de entorno SUBVERSION_HOME y Path. Figura 17. Contenido del Path con la variable de entorno SUBVERSION_HOME. Para comprobar que la instalación ha surgido efecto hay que comprobarlo con el siguiente comando “svn –version”. Figura 18. Resultado comando svn --version. SUBVERSION_HOME=C:\opt\subversion Path= …;%SURBERSION_HOME%\bin;… Vicente Ramón Orts Orts 20 4.5. Instalación Apache Tomcat 7.0.27. Todas las rutas necesaria para la instalación como la carpeta de instalación del Tomcat debería evitarse los espacios en blanco por que si no el servidor Tomcat no funcionara correctamente. Debemos crear la carpeta tomcat como se explica a continuación. Ruta correcta: c:\opt\tomcat Ruta incorrecta: c:\archivos de programa\opt\tomcat 7.0.27 En la pagina en la sección de descargas se encuentra la Source Code Distributions, posteriormente de descargar el paquete hay que extraerlo en la capeta Tomcat que hemos creado anteriormente en opt . El siguiente paso hay que crear la variable de entorno catalina_home y agregarlo al path como hemos hecho anteriormente. Código 7. Contenido de las variables de entorno CATALAINA_HOME y Path. Figura 19. Contenido del Path con la variable de entorno CATALINA_HOME. Hay que modificar el archivo que se encuentra en CATALINA_HOME\conf llamado server.xml añadiendo URIEncoding="UTF-8" después de <Conector port=”8080” Código 8. Modificación del archivo server.xml. CATALINA_HOME=C:\opt\tomcat Path= …;%CATALINA_HOME%\bin;… <Connector port="8080" URIEncoding="UTF-8" ... Vicente Ramón Orts Orts 21 Figura 20. Imagen de la modificación del archivo server.xml. Dentro de CATALINA_HOME\bin hay que crear el archivo setenv.bat con el siguiente contenido. Código 9. Contenido del archivo setenv.bat. Para acelerar la puesta en marcha del servidor Tomcat hay que borrar las webapps que se encuentran dentro de la carpeta c:\opt\tomcat\webapps con el siguiente comando: “rmdir /s webapps\*”. Con las siguiente modificaciones se configura el Tomcat 7 para que puede usar las viejas clases del Tomcat 5.5. Dentro del archivo de configuración CATALINA_HOME\conf\catalina.properties hay que añadir las siguientes líneas. Agregue a la línea "common.loader=..." : Código 10. Contenido de la variable common.loader en el archivo catalina.properties. Agregue a la línea "shared.loader=..." : Código 11. Contenido de la variable shared.loader en el archivo catalina.properties. set JAVA_OPTS=-server -Xmx1028m -XX:MaxPermSize=320m - Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING= false -Djava.awt.headless=true - Dcom.sun.management.jmxremote - Dsun.lang.ClassLoader.allowArraySyntax=true ${catalina.base}/common/classes/,${catalina.base}/co mmon/lib/*.jar ${catalina.base}/shared/classes/,${catalina.base}/s hared/lib/*.jar Vicente Ramón Orts Orts 22  Agregue a la línea "server.loader=..." : Código 12. Contenido de la variable server.loader en el archivo catalina.properties. 4.6. Instalación MySQL connector/J. Hay que descargarse la versión que corresponda a la instalación de MySQL. En este enlace http://www.mysql.com/downloads/connector/j/ se encuentran para la versión de MySQL 5.1. La instalación es muy sencilla, hay que descomprimir el paquete que nos hemos bajado, que consta de un archivo JAR que es el que utilizaremos para acabar la instalación. Posteriormente hay que copiar el JAR que hemos descomprimido dentro del directorio CATALINA_HOME\lib, posteriormente podemos borrar la carpeta que hemos utilizado para la descompresión. 4.7. Descargar Sakai 2.10-SNAPSHOT. Primeramente debemos crear la carpeta sakai-src dentro de nuestra carpeta opt, bajaremos la versión de Sakai mediante la herramienta de subversion y nos situaremos dentro de ella. Código 13. Comando necesario para descarga el Sakai. Con el anterior comando bajaremos la ultima versión de Sakai que se encuentra en el Trunk, la línea principal de desarrollo, donde se llevan a cabo los cambios menos complejos del día a día. Idealmente debería poder compilarse y pasar todas las pruebas en todo momento. La descarga durara unos 5 o 10 minutos. 4.8. Configurar Sakai 2.10-SNAPSHOT. Dentro de CATALINA_HOME crearemos la carpeta Sakai y copiaremos en ella el archivo de configuración de Sakai que se encuentra en c:\opt\sakai-src\ config\configuration\bundles\src\bundle\org\sakaiproject\config\bundle\ llamado default.sakai.properties. Necesitamos editar unas líneas del archivo default.sakai.properties de la siguiente forma: Todas las modificaciones se harán en la sección del archivo llamada # DATABASE: ${catalina.base}/server/classes/,${catalina.base}/se rver/lib/*.jar svn cheakout https://source.sakaiproject.org/svn/sakai/trunk/ Vicente Ramón Orts Orts 23 1. Editar la línea BaseDataSource username quedando de esta forma: [email protected]=sakai 2. Editar la línea BaseDataSource password quedando de esta forma: [email protected]=ironchef A continuación hay que comentar estas líneas en la siguiente sección # HSQLDB settings: Código 14. Líneas que se deben comentar en el archivo default.sakai.properties. A continuación hay que descomentar estas líneas en la siguiente sección # MySQL settings: Código 15. Líneas que se deben descomentar en el archivo default.sakai.properties # HSQLDB settings (DEFAULT) #[email protected]=hsqldb #[email protected]=org.hsqldb. jdbcDriver #hibernate.dialect=org.hibernate.dialect.HSQLDialect #[email protected]=select 1 from INFORMATION_SCHEMA.SYSTEM_USERS # Two hsqldb storage options: first for in-memory (no persistence between runs), second for disk based. #[email protected]=jdbc:hsqldb:mem:sakai #[email protected]=jdbc:hsqldb:file:${saka i.home}db/sakai.db # MySQL settings [email protected]=mysql [email protected]=com.mysql.jd bc.Driver hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBD ialect [email protected]=jdbc:mysql://127.0.0.1:3 306/sakai?useUnicode=true&characterEncoding=UTF-8 [email protected]=select 1 from DUAL [email protected] ource=TRANSACTION_READ_COMMITTED Vicente Ramón Orts Orts 24 4.9. Configurar Maven. Debemos crear un nuevo archivo XML llamado setting.xml en el directorio .m2 que se encuentra en directorio de conexión del usuario probablemente en C:\documents and settings\<username> . El archivo setting.xml debe contener lo siguiente, si no habéis seguido este manual y el directorio del Tomcat es otro al recomendado aquí debéis modificar en el archivo XML la ruta del programa. Código 16. Contenido recomendado archivo setting.xml. 4.10. Despliegue Sakai. Desde el directorio sakai-src hay que ejecutar el siguiente comando “mvn clean install” con la consola para compilar si es necesario nuestros fuentes, les pasará los test, generará el jar y lo copiará en nuestro repositorio local de jars, en nuestro ordenador. Esta operación hace que ese jar esté disponible para otros proyectos maven que tengamos en nuestro ordenador. <settings xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <profiles> <profile> <id>tomcat5x</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <appserver.id>tomcat5x</appserver.id> <appserver.home>c:\opt\tomcat</appserver.home> <maven.tomcat.home>c:\opt\tomcat</maven.tomcat.home> <sakai.appserver.home>c:\opt\tomcat</sakai.appserver.home> <surefire.reportFormat>plain</surefire.reportFormat> <surefire.useFile>false</surefire.useFile> </properties> </profile> </profiles> </settings> Vicente Ramón Orts Orts 25 Cuando el Maven acabe el clean e install que tardara bastantes minutos hay que ejecutar el siguiente comando “mvn sakai:deploy” con ello lograremos subir todo nuestro repositorio del Sakai a nuestro servidor Tomcat. Cuando acabe la ejecución tendremos construido nuestra distribución del Sakai y desplegada en el servidor. Figura 22. Resultado del despliegue del Sakai. Figura 21. Resultado de la ejecución del comando mvn clean install. Vicente Ramón Orts Orts 32 Figura 28. Pagina de inicio posterior a la autentificación del Administrador. Después de comprobar que todo funciona perfectamente podemos para nuestro servidor mediante el comando “catalina stop” o ejecutando el script CATALINA_HOME\bin\shutdown. 4.13. Instalación Eclipse. Podemos bajar la ultima versión de Eclipse de la siguiente pagina http://www.eclipse.org/, debemos de bajar la versión Eclipse IDE for Java EE Developers, que cuenta con las siguientes características: http://www.eclipse.org/downloads/packages/eclipse-ide-java-eedevelopers/indigosr2 La instalación es sencilla y rápida solamente hay que extraer los archivos del zip que nos hemos bajado anteriormente en el lugar que deseamos, preferiblemente en nuestra carpeta opt\eclipse. Vicente Ramón Orts Orts 33 Figura 29. Imagen de la carga del programa Eclipse. Después de comprobar que ha funcionado correctamente la instalación, ejecutando el archivo eclipse.exe de la carpeta que hemos creado anteriormente, debemos editar el archivo eclipse.ini, debe de estar situado en el directorio de instalación del Eclipse, para cambiar las opciones por defecto de memoria del eclipse. Hay que buscar unas opciones como estas: Código 19. Opciones de memoria de Eclipse. Cambiar la configuración con estas por estas opciones: Código 20. Opciones de inicio de Eclipse. Para finalizar, la JVM (Java Virtual Machine) por defecto será la JRE (Java Runtime Environment), el Eclipse tendrá un mejor funcionamiento si la cambiamos por la J2SE (Java to Standard Edition). Debemos realizar los siguientes pasos: 1. Iniciar el Eclipse. 2. Seleccionar Window -> Preferences -> Java -> Installed JREs. -vmargs -Xms40m -Xmx256m --launcher.XXMaxPermSize 256M -vmargs -Xms128m -Xmx1024m -XX:+UseParallelGC Vicente Ramón Orts Orts 34 Figura 30. Preferencias del Eclipse. 3. Seleccionar la versión actualmente instalada y editar. 4. Haga clic en Examinar y navegue hasta el directorio de la instalación de JDK que hemos instalado en el punto 3.1. Vicente Ramón Orts Orts 35 Figura 31. Edición del JRE. 5. Haga clic en Aceptar para guardar y luego en Aceptar para finalizar. También existe la opción de inicio –vm [ruta instalación java] cuando se ejecuta desde la consola el Eclipse, para poder elegir la instalación de java que mas nos convenga. 4.13.1. Instalación plugin Subclipse. Para instalar cualquier plugin de Eclipse necesitamos seguir los siguiente pasos: 1. Iniciar eclipse. 2. Seleccionar Help -> Install New Software… Vicente Ramón Orts Orts 36 Figura 32. Pantalla de instalación de nuevos componentes. 3. Copiar la url de Subclipse http://subclipse.tigris.org/update_1.8.x/ en el apartado Work with: y pulsamos en Next. 4. Rellenar el apartado Name con el nombre Subclipse y pulsamos OK. Figura 33. Pantalla con formulario que sirve para añadir nuevos repositorios de plugins. 5. Seleccionar todo y pulsamos en Next. Vicente Ramón Orts Orts 37 Figura 34. Paquetes pertenecientes a la instalación de Subeclipse. 6. Aceptar los términos y pulsamos en Finish. Figura 35. Condiciones instalación Subclipse. 7. Esperar a que acabe la instalación y pedirá el reinicio de la aplicación. Vicente Ramón Orts Orts 38 Figura 36. Petición de reinicio de Eclipse. 4.13.2. Instalación plugin Maven. Para facilitarnos el desarrollo de las aplicación para Sakai necesitamos instalar el plugin Maven para resolver las dependencias entre módulos y aplicaciones. 1. Iniciar eclipse. 2. Seleccionar Help -> Install New Software… 3. Copiar la url del plugin de Maven para eclipse en el apartado Work with: y pulsamos en Next. 3. Rellenar el apartado Name con el nombre Maven y pulsamos OK. 4. Seleccionar todo y pulsamos en Next. Figura 37. Paquetes pertenecientes a la instalación de Maven2Eclipse. 5. Aceptar los términos y pulsamos en Finish. 6. Esperar a que acabe la instalación y pedirá el reinicio de la aplicación. Vicente Ramón Orts Orts 39 4.14. Integrar Sakai en Eclipse. A continuación hay que importar todos los proyectos que nos hemos de la ultima distribución de Sakai al Eclipse, para poder trabajar con ella mas cómodamente. Primeramente podemos preparar los proyectos para la importación al Eclipse no es necesario y podemos obviar este paso. Debemos situarnos desde la consola dentro de la carpeta de sakai-src y ejecutar los siguientes comandos: Código 21. Instrucciones para adaptar la aplicación a Eclipse. Seguidamente debemos cambiar el directorio de trabajo en File -> Switch Workspace -> Other… por uno nuevo que crearemos en la carpeta opt llamado WS-Sakai, posteriormente Eclipse nos pediré que lo reiniciemos. Figura 38. Selección del directorio de trabajo. Debemos agregar una nueva variable M2_REPO a Window -> Preferences -> Java -> Build Path -> Classpath Variables le asignaremos el directorio de nuestro repositorio Maven de que debe de estar en C:\<USER_HOME>\.m2\repository. mvn clean:eclipe mvn org.apache.maven.plugins:maven-eclipseplugin:2.7:m2eclipse Vicente Ramón Orts Orts 40 Figura 39. Preferencias de Eclipse, sección Classpath Variables. Debemos cambiar la perspectiva de Elipse por la de java en Window -> Open Perspective -> Java. Además debemos deseleccionar la opción de construcción automática en Project -> Build automatically. Ya estamos preparados para importar los proyectos del Sakai, seleccionamos File -> Import -> Existing Projects into Workspace. Figura 40. Selección de tipo de archivo a importar. Vicente Ramón Orts Orts 41 Debemos seleccionar en el siguiente menú, Select root directory:, el directorio donde tenemos descargada la distribución de Sakai. Figura 41. Proyectos seleccionados para importar al Eclipse. Seleccionamos todos los proyectos y la opción de copiar al directorio de trabajo y pulsamos en Finish para finalizar la importación. Si de esta forma el Eclipse no encuentra los proyectos de Sakai los podemos agregar como proyectos Maven con los mismos pasos. Seguidamente debemos limpiar todos los proyectos y volver a construirlos de la siguiente forma: 1. Seleccionar Project -> Clean. 2. Seleccionar Clean all projects. 3. Seleccionar Start a build immediately. 4. Pulsamos en OK. 5. Seleccionar Project -> Build All. Al finalizar tendremos en la consola cientos de advertencias, pero no debemos preocuparnos de ellas. Vicente Ramón Orts Orts 48 Figura 47. Visualización del mercury site. Después de seguir estos pasos tendremos disponible nuestra aplicación en el sitio mercury site y podemos probar todas las funcionalidades que hemos desarrollado. Vicente Ramón Orts Orts 49 6. Pruebas de la aplicación. En el ciclo de vida de una aplicación la fase de pruebas es la mas importante y la mas descuidada. En esta fase es donde se demuestra lo robusta y eficiente que es un aplicación. 6.1. Estrategias de prueba. En este punto se intentara averiguar cual es la estrategia mas adecuada para llevar a cabo las pruebas en toda la aplicación de tal forma que finalice la fase con satisfacción del cliente y los usuarios. Así, para realizar una buena estrategia de pruebas que cubra toso el software desarrollado, es necesario realizar las pruebas desde dentro hacia fuera, es decir, comenzar con módulos unitarios y acabar con el sistema completo. Es importante que cuando se termina una fase del ciclo de vida se desarrollen las pruebas pertinentes antes de empezar una nueva fase, para poder evitar arrastrar errores durante todo el desarrollo. En la siguiente figura se puede ver las interacciones y correspondencia entre fases y pruebas. Figura 48. Interacciones entre fases y pruebas. 6.1.1. Pruebas unitarias. Las pruebas unitarias se corresponden con la prueba de cada uno de módulos o clases de la aplicación de forma independiente y es realizada por el desarrollador en su entorno de trabajo. En resumen, consiste en probar los bloques mas pequeños con identidad propia presentes dentro de la aplicación. De esta forma, si una prueba descubre un error, este esta mas aislado y tiene mas fácil solución. Las pruebas de los módulos puede ser simultanea. Fases de desarrollo Codificación Diseño detallado Diseño de arquitectura Requisitos software Requisitos de sistema Requisitos de usuario Proceso de pruebas Pruebas de unidad Pruebas de integración Pruebas de validación Pruebas de sistema Pruebas de aceptación Vicente Ramón Orts Orts 50 La forma de abordar las pruebas unitaria es la técnica de caja blanca. Para ellos se necesitan dos tipos de módulos. Un modulo conductor o modulo impulsor que consiste en un modulo creado para la prueba que llama al modulo a probar. Y un modulo de resguardo o modulo auxiliar y este es llamado por el modulo que se quiere probar. Los módulos conductores realizan el paso de parámetros o variables hacia el modulo ha probar y existen un modulo de resguardo por cada llamada que realice el modulo ha probar. De esta forma se prueban todos los módulos de forma independiente y se corrigen los errores surgidos. 6.1.2. Pruebas de integración. En esta etapa se integran los módulos o clases, ya probados de forma independiente en las pruebas unitarias centrándose en probar las interfaces. Habitualmente se utiliza el enfoque de caja negra, se les proporciona unos datos d entrada y se evalúa si el resultado de los datos es la correcta sin tener en cuenta el funcionamiento de los módulos. Existe un problema que es determinar la forma en que interactúan los distintos módulos entre ellos, existen dos enfoques básicos. Prueba no incremental: en la que no hay un procedimiento establecido y se van integrando los módulos sin ningún orden establecido. Prueba incremental: en la que se supone un diseño en forma jerárquica y establece un orden. Los módulos se van integrando poco a poco con unas especificación establecidas. Existen tres tipos de pruebas de integración ascendentes, descendentes y sándwich. Ascendentes: se empieza integrando los módulos mas interiores y se continúa desde dentro hacia fuera. Descendentes: se empieza con el modulo superior y se continua hacia dentro por la jerarquía de control. Sándwich: esta estrategia combina las dos anteriores. Se empieza con las dos estrategias en paralelo y las pruebas terminan cuando se encuentran en un modulo. 6.1.3. Pruebas de validación. Estas pruebas se suelen llamar pruebas de validación y sirven para comprobar que se cumplen los requisitos del usuario. En esta fase intervine también el usuario y se realizan en el entorno de desarrollo. Los criterios de validación usados en esta fase son aquellos que se acordaron con el cliente o usuario al principio del proyecto en la fase de definición de requisitos. En esta fase lo relevante son las salidas producidas por el sistema, así que se usa una estrategia de caja negra. Las pruebas constan de dos partes:  La validación por parte del usuario para comprobar si los resultados producidos son los correctos.  La utilidad, facilidad de uso y ergonomía de la interfaz del usuario. Vicente Ramón Orts Orts 51 Para probar que cumplen los requisitos anteriores suele usarse un matriz de trazabilidad que se pone en las columnas los módulos y en las filas los requerimientos. Se traza una cruz en las celdas que corresponden con el modulo y requerimiento que cumple. A continuación, se muestra un ejemplo de matriz de trazabilidad. Modulo Requisito Modulo 1 Modulo 2 Modulo 3 … Modulo n Requisito 1 X … X Requisito n X Figura 49. Ejemplo de matriz de trazabilidad. 6.1.4. Pruebas de aceptación. El ultimo paso del desarrollo de software son las pruebas de aceptación, normalmente, en el entorno de usuario. Consiste en la aceptación por parte del cliente de la aplicación desarrollado. El cliente comprueba que el sistema esta listo para su uso operativo y que satisface sus expectativas. Los casos de prueba suelen ser proporcionados por el cliente. Si el software se trata de una herramienta para el mercado, se suelen llevar a cabo las pruebas RTM testing (Release to Market). En estas pruebas se comprueba cada funcionalidad del sistema completo en el entorno real de producción. 6.2. Pruebas unitarias con JUnit. En este punto trataremos de explicar el funcionamiento de la realización de pruebas con la herramienta JUnit y las pruebas unitarias de los componentes principales de nuestra aplicación. 6.2.1 JUnit JUnit es un framework que permite la automatización de las pruebas unitarias sobre clases desarrolladas en lenguaje java. Fue creado en 1997 por Erich Gamma y Kent Beck basándose inicialmente en un framework para Smaltalk llamado SUnit y que fue desarrollado por este ultimo. JUnit es un poryecto de código abierto escrito en Java y distribuido baja la licencia Common Public License Version 1.0. y esta disponible para libre descarga. Un Framework, en su acepción más amplia, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, con base a la cual otro proyecto de software puede ser más fácilmente organizado y desarrollado. Típicamente, puede incluir soporte de programas, Vicente Ramón Orts Orts 52 bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de un proyecto. 6.2.2. Instalación de JUnit. Para poder utilizar las herramienta de JUnit en nuestra aplicación necesitaremos la ultima versión estable de JUnit que se trata de la versión 4.10. Primero necesitaremos agregar al pom de nuestra aplicación las siguientes líneas para indicarle al Maven que necesitamos una nueva dependencia. Posteriormente debemos agregar en cada pom de los módulos de nuestra aplicación, que queramos crear una clase JUnit para realizar las pruebas unitarias, las siguientes líneas para indicarle la dependencia necesaria para la ejecución de JUnit. Código 26. Líneas necesarias para la creación de la dependencia JUnit en los módulos. Ahora ya tenemos todas clases necesarias para realizar las pruebas unitarias con JUnit, cuando realicemos el despliegue de nuestra aplicación automáticamente Maven descargara las dependencias que le hemos indicado anteriormente en los archivos POM. 6.2.3. Elementos de las pruebas con JUnit. En este punto explicaremos elementos de las clases JUnit para las pruebas unitarias de clases o módulos. Utilizaremos para la explicación un ejemplo muy sencillo, recogido en las distribuciones anteriores del JUnit, donde se comprueba que los métodos size y clone de un vector funcionan correctamente. En la siguiente figura se presenta el archivo que contiene las pruebas unitarias. <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.10</version> </dependency> Código 25. Dependencia Maven del JUnit <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId </dependency> Vicente Ramón Orts Orts 53 Código 27. Clase de pruebas VectorTest. Este ejemplo consiste en una clase VectorTest que se encarga de probar la clase Vector, tiene como únicos atributos dos vectores. Para ello se definen dos métodos testCapacidad y testClonar que contienen un serie de instrucciones que permiten comprobar el funcionamiento de los métodos size y clone de un vector. Para inicializar todas las variables necesarias para llevar a cabo los test se utiliza el método setUp que se llama antes de la realización de los test. En este caso inicializa los vectores y añade tres elementos a uno de los dos vectores y deja el otro vacío. Además se necesitan el método suite y la funciona main, que hacen uso de los mecanismos que proporciona JUnit para ejecutar los métodos de prueba definidos en esta clase y mostrar los resultados. Los métodos de los test realizan las siguientes instrucciones: testCapacidad: Inicializa el vector vVacio a 100 elementos y comprueba que el método size devuelve el valor 100. Código 28. Método testCapacidad. testClonar: Crea un nuevo vector vClonado con el método clonar y el vector vLleno, se comprueba que tienen los dos vectores, vClonado y el original, la misma longitud y se comprueba al azar que el vector vClonado tiene uno de los elementos originales. import junit.framework.*; import java.util.Vector; public class VectorTest extends TestCase{ protected Vector vLleno; protected Vector vVacio; public static void main(String[] args){ junit.textui.TestRunner.run(suite()); } protected void setUp(){ vLleno= new Vector(); vVacio= new Vector(); vLLeno.addElement(new Integer(1)); vLLeno.addElement(new Integer(2)); vLLeno.addElement(new Integer(3)); } public static Test suite(){ return new TestSuite(VectorTest.class); } public void testCapacidad(){…} public void testClonar(){…} } public void testCapacidad(){ int tamaño= vVacio.size(); for (int i= 0; i < 100; i++) vVacio.addElement(new Integer(i)); assertTrue(vVacio.size() == tamaño+100); } Vicente Ramón Orts Orts 54 Código 29. Método testClonar. Con las instrucciones assert se comprueba que las instrucciones ha probar devuelven el valor esperado, en este caso se utiliza assertTrue para probar si el resultado es verdadero o falso. 6.2.4. Creación de una clase de pruebas para eShop. Una vez puesto a punto nuestro entorno de pruebas y conocer los elementos que necesitamos para realizarlas, pondremos un ejemplo de como crear una clase de prueba para comprobar el funcionamiento de los métodos o las clases que necesitemos. Un buen método es crear una clase de prueba por cada clase de nuestra aplicación. Para empezar debemos saber donde situar las clases de prueba, aunque en un principio se pueden situar en cualquier lugar de la nuestra aplicación, se recomienda dejarlas todas en el mismo lugar para poderlas gestionar fácilmente. Nosotros hemos optado por situarlas dentro de la siguiente ruta [Nombre Aplicación]\tool\src\test, esta ruta esta comprobada, cuando se ejecuta el despliegue de la aplicación esta encuentra las pruebas. Para crear una nueva clase de pruebas desde el Eclipse, debemos hacer los siguiente: 1. Situarnos dentro de nuestra aplicación. 2. Seleccionar File -> New -> Other... 3. Seleccionar JUnit Test Case. public void testCapacidad(){ Vector vClonado=(Vector)vLleno.clone(); assertTrue(vClonado.size() == vLleno.size()); assertTrue(vClonado.contains(new Integer(1))); } Figura 50. Ventana selección creación nuevos archivos. Vicente Ramón Orts Orts 55 4. Darle un nombre a nuestra clase, debería ser nombre de la clase a probar más la palabra test. 5. Seleccionar la ruta donde queremos agregar la clase en Source Folder: 6. Seleccionar el paquete al que pertenece nuestra aplicación en Package: 7. Seleccionar los métodos que queremos que nos cree, setUp. Figura 51. Creación JUnit Test Case. 8. Pulsar Finish. En la siguiente figura puede verse los métodos necesarios para llevar a cabo las pruebas unitarias en nuestra aplicación. public class UserTest extends TestCase { private String id; private String email; private String password; private String creditCardNo; public void setUp(){ id="uno"; email="uno@mail"; password="123456"; creditCardNo="11111"; } public static void main(String[] args) { junit.textui.TestRunner.run(suite()); } public static junit.framework.Test suite() { return new TestSuite(UserTest.class); } @Test public void testConctructorUser(){…} @Test public void testAutentificacionUser(){…} @Test public void testSetGetUser(){…} } Código 30. Cuerpo Principal de la clase UserTest. Vicente Ramón Orts Orts 56 En la siguiente figura puede verse los métodos que se han creado para probar nuestra clase Usuario, pasamos a describir el funcionamiento de cada uno de ellos. testConctructorUser: para probar un constructor se debe hacer una prueba de caja blanca para probar el correcto funcionamiento. Primero construiremos un usuario con el constructor por defecto con unos atributos determinados que guardaremos. Y a continuación debemos comprobar que el objeto anteriormente creado tiene los atributos que le hemos proporcionado, comparándolos con los guardados. testSetGetUser: construimos un objeto vacío y con los métodos set’s se almacena unos valores predeterminados, que se han guardado con anterioridad. A continuación recuperamos los valores almacenados con los métodos get’s y los comparamos con los guardados, si tienen el mismo valor quiere decir que los métodos funcionan correctamente. testAutentificacionUser: para probar métodos convencionales, que no son ni constructores, ni get’s, ni set’s. Los métodos convencionales suelen ser mas complejos, no siguen una estructura preestablecida y se debe de conocer su código en profundidad para poder realizar las pruebas pertinentes. En este caso se creara un objeto con unos parámetros que se guardaran, se invocara el método con datos de entrada correctos y otros incorrectos, para finalizar se realizara la comprobación de si el resultado es el esperado. Para los datos correctos true y para los incorrectos false. @Test public void testConctructorUser(){ User usuario=new User(id,email,password,creditCardNo); assertEquals(id,usuario.getId()); assertEquals(email,usuario.getEmail()); assertEquals(password,usuario.getPassword()); assertEquals(creditCardNo,usuario.getCreditCardNo()); } @Test public void testAutentificacionUser(){ User usuario=new User(id,email,password,creditCardNo); assertTrue(usuario.authenticate(email, password)); assertFalse(usuario.authenticate("dos@email", password)); } @Test public void testSetGetUser(){ User usuario=new User("","","",""); usuario.setId(id); usuario.setEmail(email); usuario.setPassword(password); usuario.setCreditCardNo(creditCardNo); assertEquals(id,usuario.getId()); assertEquals(email,usuario.getEmail()); assertEquals(password,usuario.getPassword()); assertEquals(creditCardNo,usuario.getCreditCardNo()); } Código 31. Código de los métodos test. Vicente Ramón Orts Orts 57 Debemos seguir la misma política en cuestión de pruebas para el resto de las clases, aunque parezca un trabajo arduo nos proporcionara la seguridad de que nuestros métodos funcionan correctamente y se comportan de la forma esperada. Para ejecutar las pruebas del ejemplo anterior podemos utilizar la propia herramienta grafica del eclipse o mediante el comando de la utilidad de Maven “mvn test”. Debemos situarnos con la consola del sistema dentro de la carpeta de nuestro proyecto y ejecutar el comando anterior. En la siguiente captura se refleja el resultado de la ejecución de los test unitarios. 6.3. Estándar de pruebas. Existen dos estándares referentes a la creación de aplicación y pruebas de software, estos son IEEE829, para documentar pruebas y la norma ISO 9126, modelo de Calidad. 6.3.1. IEEE 829 Se trata de un estándar que especifica la estructura de una serie de documentos usados en ocho etapas de software testing, cada una de ellas con su tipo independiente de documento. Sin embargo, la norma no especifica cuando se deben generar ni incluye criterios sobre el contenido de los mismos, aspectos que sujetos a juicio y que escapan a la norma. Los documentos son: 1. Test plan: Un documento que gestiona el plan de pruebas y que indica: cómo se realizarán las pruebas, incluyendo la configuración del sistema a probar, quién realizará las pruebas, qué se probará, cuánto tiempo tardarán y cuál será la cobertura de las pruebas. 2. Especificación del diseño de los test: Detalle de las condiciones de los test y los resultados esperados, así como el criterio a seguir para considerar una prueba como superada. Figura 52. Resultado UserTest.