Qué ofrece Autentia Real Business Solutions S.L?

Transcripción

1 Qué ofrece Autentia Real Business Solutions S.L? Somos su empresa de Soporte a Desarrollo Informático. Ese apoyo que siempre quiso tener Avenida de Castilla,1 - Edificio Best Point - Oficina 21B San Fernando de Henares (Madrid) tel./fax: info@autentia.com Desarrollo de componentes y proyectos a medida 2. Auditoría de código y recomendaciones de mejora 3. Arranque de proyectos basados en nuevas tecnologías 1. Definición de frameworks corporativos. 2. Transferencia de conocimiento de nuevas arquitecturas. 3. Soporte al arranque de proyectos. 4. Auditoría preventiva periódica de calidad. 5. Revisión previa a la certificación de proyectos. 6. Extensión de capacidad de equipos de calidad. 7. Identificación de problemas en producción. 3a Gran Empresa Tecnología Desarrollo Sistemas Piloto RFP 3b Concurso Consultora 1 Consultora 2 Consultora 3 Equipo propio desarrollo Verificación previa Certificación o Pruebas Producción autentia 4. Cursos de formación (impartidos por desarrolladores en activo) Spring MVC, JSF-PrimeFaces /RichFaces, HTML5, CSS3, JavaScript-jQuery Gestor portales (Liferay) Gestor de contenidos (Alfresco) Aplicaciones híbridas Control de autenticación y acceso (Spring Security) UDDI Web Services Rest Services Social SSO SSO (Cas) JPA-Hibernate, MyBatis Motor de búsqueda empresarial (Solr) ETL (Talend) Dirección de Proyectos Informáticos. Metodologías ágiles Patrones de diseño TDD Tareas programadas (Quartz) Gestor documental (Alfresco) Inversión de control (Spring) BPM (jbpm o Bonita) Generación de informes (JasperReport) ESB (Open ESB) Compartimos nuestro conociemiento en: Para más información visítenos en:

2 Entra en Adictos a través de Entrar Deseo registrarme Olvidé mi contraseña Inicio Quiénes somos Formación Comparador de salarios Nuestros libros Más MS» Estás en: Inicio Tutoriales Maven, Jenkins, Sonar y tests de integracion Borja Lázaro de Rafael Consultor tecnológico de desarrollo de proyectos informáticos. Catálogo de servicios Autentia Ingeniero en Informática Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación Somos expertos en Java/J2EE Ver todos los tutoriales del autor Fecha de publicación del tutorial: Tutorial visitado 1 veces Descargar en PDF Maven, Jenkins, Sonar y tests de integracion 0. Índice de contenidos. 1. Introducción 2. Entorno 3. Configuración básica de Maven 4. Conseguir que las builds de Jenkins no fallen 5. Tener las métricas en Sonar 6. Conclusiones Síguenos a través de: 1. Introducción En otros tutoriales ya hemos hablando varias veces de cómo hacer tests unitarios e incluso cómo podemos hacer tests de integración levantando el contexto de Spring o un contexto JEE con Arquilian. Estos tests sin dejar de ser tests de integración, porque dependen de su éxito no sólo de la correcta implementación de la pieza que estoy probando, tienen la ventaja de que todo el contexto auxiliar del que dependen lo podemos proporcionar dentro de nuestros proyecto y seguimos teniendo el control del mismo; por lo que se ejecutan y suman sus métricas como si fueran tests unitarios. Sin embargo no siempre es posible proporcionar estos "mini-contextos" y nuestras aplicaciones en muchos casos no corren aisladas, en muchos casos hay que conectarse a muchos otros servidores con distintos protocolos, HTTP, FTP, SSH, Samba, etc. En estos casos es en los que nos vamos a centrar. Queremos hacer tests de integración que sumen en las métricas de cobertura y de tests para saber cuanto código tengo probado y llevar un control del total de tests ejecutados, exitos, fallos e ignorados. Dadas estos objetivos, damos por sentado que ya tenemos montado nuestro entorno de integración contínua con Maven, Jenkins y Sonar; así que sumamos a nuestra lista de desables que todo quede integrado de una manera ejecutiva. En este tutorial contamos el añadido de configuración necesario para tener estos tests de integración añadidos en nuestras métricas y bajo control, sin entrar a contar cómo se monta todo un entorno de integración contínua que queda fuera del alcance propio del tutorial. 2. Entorno Este tutorial está escrito usando el siguiente entorno: Hardware: Portátil MacBook Pro Retina 15' (2,3 GHz Intel Core i7, 16GB DDR3 SDRAM). Sistema Operativo: Mac OS X Lion Apache Maven Jenkins Sonar Configuración básica de Maven Este tipo de tests podríamos ejecutarlos como el resto de tests unitarios, pero entonces todo el entorno del que dependen debería estar disponible en cualquier sitio donde ejecutase los tests, y recordemos que estamos hablando de tests de integración y no de tests unitarios. Incluso podría darse el caso de que incluso en el entorno de integración fallasen los tests debido a la inestabilidad de estos sistemas externos; en tal caso puede que no nos interesa que se aborten las "builds" aunque si que se deberían generar alertas, y si estos test se ejecutan en la fase de "test" de Maven junto al resto, cuando fallan se aborta la ejecución. Últimas Noticias» Aprende gratis ReactiveCocoa» Checklist de Scrum de Autentia» Autentia estrena web y celebra el X Cycling Day» Buscamos personal para Autentia y nuestros clientes (10-Marzo-2014)» Charla de Auto Layout en nuestra oficina Histórico de noticias Últimos Tutoriales» Spring Ldap: gestión de transacciones y configuración de un pool de conexiones» Spring Ldap: operaciones básicas haciendo uso del soporte de plantillas» Crear un plugin para Android en PhoneGap» Implementando tu propio Writable en Hadoop 1 of 4 11/04/14 14:14

3 PUSH THIS Page Pushers Community Help? people brought clicks to this page no clicks powered by karmacracy Otro motivo, yo diría que aún más importante para que no se aborte la ejecución en caso de fallo, es que puede que nos interese cerrar/limpiar/liberar un contexto, que se necesite para la ejecución del test, haya o no fallado el test. Por suerte Maven ya tiene previsto estas situaciones y tiene definido en su ciclo de vida las fases "pre-integration-test", "integration-test" y "post-integration-test". Para poder beneficiarnos de esta característica de Maven sólo tenemos que hacer uso del plugin de Maven Failsafe que con la configuración básica y cumpliendo con la convención de llamar a nuestros tests de integración con el sufijo "IT" ya tendríamos el mínimo:» Cómo añadir Volley (librería de Android) en Android Studio Últimos Tutoriales del Autor <build> <plugins>. <artifactid>maven-failsafe-plugin</artifactid> <dependencies> <dependency> <groupid>org.apache.maven.surefire</groupid> <artifactid>surefire-junit47</artifactid> </dependency> </dependencies> <testfailureignore>true</testfailureignore> <goal>integration-test</goal> <goal>verify</goal> </plugins> </build>?» Prototipado de pantallas con Pencil» Token con caducidad en Spring Security» Gestión de eventos en el cliente con el soporte Ajax de PrimeFaces» Usando el componente PickList de Primefaces» Release Bugzilla Maven Plugin Nota: Según la convención también podríamos llamar a estos tests con el sufijo "IntegrationTest" pero al terminar en "Test" también se ejecutarían en la fase de "Test" y no nos interesa. 4. Conseguir que las builds de Jenkins no fallen Por suerte, Jenkins y Maven se integran perfectamente y con la configuración del Failsafe plugin indicando "testfailureignore" a "true" Jenkins ya lo tiene en cuenta y si los tests que se ejecutan en la fase de "integration-tests" fallan se continúa con la "build" y no se marca como fallo. En caso de fallar algún test de integración la "build" se marca como inestable y se enviarán notificaciones si así está configurado. Así que en lo que respecta a Jenkins no tenemos que tocar ninguna configuración adicional, y se seguirá ejecutando tal y como hasta ahora. 5. Tener las métricas en Sonar Ahora que ya ejecutamos nuestros tests de integración, y lo hacemos en un entorno de integración continua, nos interesa explotar sus métricas junto son el resto de métricas que ya nos proporciona Sonar. En primer lugar es configurar Sonar para que nos muestre estas métricas Para hacer esto tenemos que tocar en la configuración de los Widgets de Sonar en un par de sitios. Primero configuramos en el "dashboard" que aparezca la columna "Overall Coverage", el valor de esta columna nos va a mostrar el porcentaje global de cobertura sumando el código cubierto tanto en la ejecución de tests unitarios como el de tests de integración. Por otro lado, configuramos el "dashboard" de los proyectos añadiendo el widget "Integration Tests Coverage" que nos va a mostrar 2 medidas, la cobertura específica de los tests de integración mas la cobertura global. Una vez que ya tenemos preparado Sonar, nos falta que Jenkins al ejecutar Maven de nuestro proyecto nos envíe estas métricas. Para ello hay que configurar el plugin de cobertura de JaCoCo, el mismo que utiliza Sonar por defecto, y enlazar el plugin de FailSafe con el de JaCoCo para medir la cobertura de los tets de integración. Otro problema que tenemos al ver las métricas en Sonar es que no hay ninún plugin de Sonar que nos muestre el número de tests de integración o tests globales. Así que aquí lo que vamos a hacer en una solución a modo de "workaround" que consiste 2 of 4 11/04/14 14:14

4 en sumar el número y resultado de tests de integración al de tests unitarios, de forma que el Widget de "Unit Tests Coverage" que muestra Sonar va a seguir mostrando la cobertura propia de los tests unitarios, pero en la sección de resumen, "Unit test success", no sólo mostrará los tests unitarios, también incluye la suma de los tests de integración. Para configurar esto lo haremos en nuestro POM dejando finalmente la configuración de los plugins de JaCoCo y Failsafe como sigue: ? <properties> <sonar.core.codecoverageplugin>jacoco</sonar.core.codecoverageplugin> <sonar.jacoco.itreportpath>${project.basedir}/target/jacoco-it.exec</sonar.jacoco.itre </properties> <build> <plugins> <groupid>org.jacoco</groupid> <artifactid>jacoco-maven-plugin</artifactid> <version> </version> <propertyname>jacoco.agent.argline</propertyname> <destfile>${sonar.jacoco.itreportpath}</destfile> <append>true</append> <id>agent</id> <goal>prepare-agent</goal> <artifactid>maven-failsafe-plugin</artifactid> <dependencies> <dependency> <groupid>org.apache.maven.surefire</groupid> <artifactid>surefire-junit47</artifactid> </dependency> </dependencies> <argline>${jacoco.agent.argline}</argline> <testfailureignore>true</testfailureignore> <reportsdirectory>${project.build.directory}/surefire-reports</reportsdirectory> <goal>integration-test</goal> <goal>verify</goal> </plugins> </build> 6. Conclusiones Hemos visto como conseguir tener controlados nuetsros tests de integración en un entorno de integración contínua sin que se conviertan en bloqueantes en caso de que los sitemas de terceros de los que dependen no estén disponibles y provoquen que fallen. Aunque sin perder en ningún momento las alertas ni las métricas de cobertura y éxitos de todos nuestros tests. Es cierto que la visualización del número de tests no se puede ir al grano fino y distinguir cuántos son unitarios y cuantos de integración, pero desde el punto de vista ejecutivo seguramente sea más interesante tener el resumen con la suma de ambos, y a falta de disponer del grano fino, mejor esta solución que ninguna. Espero que a alguno de vosotros os pueda servir de ayuda y os ahorre algo de trabajo dado el caso. A continuación puedes evaluarlo: Regístrate para evaluarlo Por favor, vota +1 o compártelo si te pareció interesante 3 of 4 11/04/14 14:14

5 Share 0 Anímate y coméntanos lo que pienses sobre este TUTORIAL:» Registrate y accede a esta y otras ventajas «Esta obra está licenciada bajo licencia Creative Commons de Reconocimiento-No comercial-sin obras derivadas 2.5 Copyright All Rights Reserved Texto legal y condiciones de uso Banners Powered by Autentia Contacto 4 of 4 11/04/14 14:14