El testing siempre ha sido una parte integral del desarrollo de software. Sin embargo, el camino del testing ha sido llevado ha cambios significativos a lo largo de década. Como programadores, hemos tenido siempre interés en conocer qué nuestro software trabaja, antes de que sea pasado a los usuarios . Lo que significa que obtenemos conocimiento, sin embargo, ha evolucionado obteniendo software ágil de desarrollo como es la Programación Extrema.
Adicionalmente, el rol del test de ellos mismos, ha modificado entre otras áreas del desarrollo de software, planificando la verificación para confirmar para especificar. En efecto, la solución para el segundo tiempo de nuestro problema de código es omitirlos, para encontrarse con la actual necesidad es permitir test manejados sobre el desarrollo a nivle de la construcción y funcionalmente en la construcción del sistema. Es decir, practicamente test de aceptación sobre el desarrollo. En conclusión, "Hacemos sólo pruebas de ejecución en una parte del sistema cuando los test son llamados".
En esecencia, significa que los test no son llamados meramente una verificación de instrumentos, si no como una parte integral de requerimientos y especificacion así comop también un medio para colaborar con el negocio.En esta sección , iremos introduciéndonos en más detalle sobre esos nuevos roles de los test, comenzando con examinar y nutrir la estrecha colaboración entre el desarrollo , tester , y negocio , y discutir el uso de los test como un lenguaje compartido facilitando la colaboración.
Antes de discutir los aspectos de la técnica de la colaboración orientada, debemos relacionar la relación entre los test de aceptación y TDD. Después de todo, sus nombres son apenas idénticos.
1.4.1 Cuál es su nombre?
El nombre "test de aceptación" implica que la aceptación de TDD es igualmente algo similar para "regular" TDD. El sufijo es obviamente procede de TDD, pero de donde viene el resto? Qué es test de aceptación? En conclusión , test de aceptación son indicadores de la completación de un requerimiento o aspecto. Todo test de aceptación para un requerimeinto o presentación pasada, permite saber lo que hace.
TDD de aceptación es una técnica , no es una combinación para especificar formas para expresar requerimientos. La misma idea puede ser aplicada para algunos efectos tanto como implementando casos de uso, historias , o otros medios equivalentes para documentar lo que tiene que hacer. Esto denota un valor, es decir, ese equipo usando historias para administrar sus requerimientos tienden a llamarlo "historias de test en ejecución de desarrollo" en cambio - cúal es un nombre diferente para alguna técnica. A pesar de eso otros prefieren llamarlo " test de ejecución de desarrollo de negocio", lo cual es apropiado considerando la naturalidad del test.
Nota: Sin embargo TDD y TDD de aceptación tiene mucho en común y ciertamente el hermano mayor tiene mucho que parender de su hermano menor, pero ambos TDD Y TDD de aceptación pueden ser adoptados en forma excluyentes. Los programadores que no tienen historias de usuarios a la vista que aún no pueden hacerlo para una funcionalidad determinada, todavía pueden adoptar TDD y cosechar sus beneficios tales como; equipos de prueben previamente antes de integrar funciones. Esta práctica producen una mejora más que el uso de cualquiera de ellos solos.
Independientemente del formato específico o herramienta que utilizamos para gestionar los requisitos, el principla objetivo de la Aceptación TDD es, apoyar la colaboración estrecha entre el cliente y el equpo de desarrollo. Vamos a ver como está basado en pruebas.
1.4.2 La estrecha colaboración
Estrecha colaboración es escencial para cualquier esfuerzo complejo que invlucre a personas y desarrollo de software con TDD de aceptación. En la práctica se requiere tener un equipo de proyecto integrado de desarrollo, en empresas, análisis, pruebas de equipos y departamento de control de calidad.
La idea fundamental es alcanzar el mejor nivel de productividad para todo el equipo, alimentando una respuesta rápida y eficaz cara a cara, con una buena comunicación, software de trabajo que impidan las pruebas planas, especificaciones e informes de incidencias entre los clientes, usuarios, analistas de negocios y desarrolladores. Con TDD de aceptación , somo capaces de colaborar efectivamente y reunir conocimientos , destrezas y habilidades necesarias para hacer un buen trabajo.
Veamos como la estrecha colaboración ayuda a liberar un producto correcto con la mejora de nuestras iteraciones reduciendo la probabilidad de incidencias.
Viendo concretamente el trabajo de software
Existen clientes despues de varios meses, demuestran no estar contentos o satisfechos con entregas de trabajo de contratistas.Informar al cliente con entregas continuas de funcionalidades, estamos asegurandonos de que, si hay algo incorrecto o no, lo sabremos de inmediato. Esta temprana retroalimentación reduce riesgos y costos. Además al no llevar un inventario, donde se detalle de las funcionalidades terminadas , estamos evitando mostrar el progreso del desarrollo, como por ejemplo "desarrollo es de 90% completo"
Creando confianza y confianza
Otro beneficio que se gana al realizar entregas tempranas de trabajo de software y con frecuencia es que estamos contruyendo confianza, tanto entre el equipo y el cliente como dentro del mismo equipo. Al mostrar a lo clientes (y a nosotros mismos) que podemos entregar iteraciones de versiones, estamos haciendo la vida mucho más fácil para todo nuestro equipo.
La evolución de un trabajo compartido
Al fomentar una estrecha colaboración entre los testeadores , desarrolladores y clientes, somos efectivos facilitadores a una situación donde la información necesaria se obtiene tan pronto como sea posible -en todas las direcciones. Además, esta exposición es continúa en el equipo aumentando la eficiencia en la comunicación como el conocimiento entre los desarrolladores generando un lenguaje compartido. El desarrrollo de software es un negocio de personas y no debemos descuidarnos en ello.
Vamos a ver la posibilidad de usar test de aceptación usando como fundamento un lenguaje compartido incluyendo a cliente y al equipo de desarrollo y tester.
1.4.3 Test como un lenguaje compartido
Uno de los mayores problemas en el desarrollo de software es no tener claridad de los requerimientos o necesidades del cliente. Esto deja de ser un juego de niños para expresar y comunicar los requisitos de tal forma que ninguna información pierda la transmisión de la idea original. Algunos dicen a lo lejos que es imposible realizarlo. Despues de todo , no podemos leer la mente de nuestros clientes.
Este problema es evidente cuando usamos un medio de comunicación es por medio de una documentación escrita- por ejemplo, especificaciones de requerimientos- lo cual es lejos un medio perfecto para la transferencia y comprensión de la información. Si pudieramos ser capáz de trasnformar los requisitos en pruebas ejecutables y que verificaran si el sistema se ajusta a las aspectos y condiciones particulares, habría menos problemas con las ambiguedades y el espacio entre la interpretación y los desarrolladores. Esta es la premisa perfecta de los test como especificaciónes.
Test de Pruebas como especificaciones.
Los test como especificaicones provee una manera de de ver las pruebas como algo esencial que se derivan de los requisitos, por lo que en teoría, un sistema que pasa sus pruebas , se ajustan a la especificación.
De vez en cuando, obtenemos defectos a través de pruebas. Esto no es novedad para quienes hemos estado a lo menos en dos proyectos de software comercial. Esto se debe por no considerar todas las pruebas las pruebas necesarias. En parte , esto se debe a nuestra naturaleza humana y nuestra intuición engañosa, donde , sólo se resuleven algunas incidencia para ahorra tiempo.
Esto nos plantea la pregunta, ¿Estamos realmente usando los test como especificaciones , si los tests tienden a fugarse por otros caminos? Esto es realmente factible para el uso de los test como especificaciones, efectivamente redifiniendo el significado de los conceptos?. Usando test como especificaciones no es una bala de plata, pero tiene una serie de ventajas que valen la pena considerar.
En primer lugar, no se puede negar que al tener automatizadas las pruebas ejecutables, nos deshacemos de un montón de duro trabajo, acelerando las iteraciones enormemente, si lo comporamos si lo realizamos manualmente.En segundo lugar, evita la negligencia de pereza que poseemos los humanos. Finalmente , hacemos de los errores una traducción de los verdaderos requerimientos en la escritura con verdaderas prácticas.Adicionalmente, el rol del test de ellos mismos, ha modificado entre otras áreas del desarrollo de software, planificando la verificación para confirmar para especificar. En efecto, la solución para el segundo tiempo de nuestro problema de código es omitirlos, para encontrarse con la actual necesidad es permitir test manejados sobre el desarrollo a nivle de la construcción y funcionalmente en la construcción del sistema. Es decir, practicamente test de aceptación sobre el desarrollo. En conclusión, "Hacemos sólo pruebas de ejecución en una parte del sistema cuando los test son llamados".
En esecencia, significa que los test no son llamados meramente una verificación de instrumentos, si no como una parte integral de requerimientos y especificacion así comop también un medio para colaborar con el negocio.En esta sección , iremos introduciéndonos en más detalle sobre esos nuevos roles de los test, comenzando con examinar y nutrir la estrecha colaboración entre el desarrollo , tester , y negocio , y discutir el uso de los test como un lenguaje compartido facilitando la colaboración.
Antes de discutir los aspectos de la técnica de la colaboración orientada, debemos relacionar la relación entre los test de aceptación y TDD. Después de todo, sus nombres son apenas idénticos.
1.4.1 Cuál es su nombre?
El nombre "test de aceptación" implica que la aceptación de TDD es igualmente algo similar para "regular" TDD. El sufijo es obviamente procede de TDD, pero de donde viene el resto? Qué es test de aceptación? En conclusión , test de aceptación son indicadores de la completación de un requerimiento o aspecto. Todo test de aceptación para un requerimeinto o presentación pasada, permite saber lo que hace.
TDD de aceptación es una técnica , no es una combinación para especificar formas para expresar requerimientos. La misma idea puede ser aplicada para algunos efectos tanto como implementando casos de uso, historias , o otros medios equivalentes para documentar lo que tiene que hacer. Esto denota un valor, es decir, ese equipo usando historias para administrar sus requerimientos tienden a llamarlo "historias de test en ejecución de desarrollo" en cambio - cúal es un nombre diferente para alguna técnica. A pesar de eso otros prefieren llamarlo " test de ejecución de desarrollo de negocio", lo cual es apropiado considerando la naturalidad del test.
Nota: Sin embargo TDD y TDD de aceptación tiene mucho en común y ciertamente el hermano mayor tiene mucho que parender de su hermano menor, pero ambos TDD Y TDD de aceptación pueden ser adoptados en forma excluyentes. Los programadores que no tienen historias de usuarios a la vista que aún no pueden hacerlo para una funcionalidad determinada, todavía pueden adoptar TDD y cosechar sus beneficios tales como; equipos de prueben previamente antes de integrar funciones. Esta práctica producen una mejora más que el uso de cualquiera de ellos solos.
Independientemente del formato específico o herramienta que utilizamos para gestionar los requisitos, el principla objetivo de la Aceptación TDD es, apoyar la colaboración estrecha entre el cliente y el equpo de desarrollo. Vamos a ver como está basado en pruebas.
1.4.2 La estrecha colaboración
Estrecha colaboración es escencial para cualquier esfuerzo complejo que invlucre a personas y desarrollo de software con TDD de aceptación. En la práctica se requiere tener un equipo de proyecto integrado de desarrollo, en empresas, análisis, pruebas de equipos y departamento de control de calidad.
La idea fundamental es alcanzar el mejor nivel de productividad para todo el equipo, alimentando una respuesta rápida y eficaz cara a cara, con una buena comunicación, software de trabajo que impidan las pruebas planas, especificaciones e informes de incidencias entre los clientes, usuarios, analistas de negocios y desarrolladores. Con TDD de aceptación , somo capaces de colaborar efectivamente y reunir conocimientos , destrezas y habilidades necesarias para hacer un buen trabajo.
Veamos como la estrecha colaboración ayuda a liberar un producto correcto con la mejora de nuestras iteraciones reduciendo la probabilidad de incidencias.
Viendo concretamente el trabajo de software
Existen clientes despues de varios meses, demuestran no estar contentos o satisfechos con entregas de trabajo de contratistas.Informar al cliente con entregas continuas de funcionalidades, estamos asegurandonos de que, si hay algo incorrecto o no, lo sabremos de inmediato. Esta temprana retroalimentación reduce riesgos y costos. Además al no llevar un inventario, donde se detalle de las funcionalidades terminadas , estamos evitando mostrar el progreso del desarrollo, como por ejemplo "desarrollo es de 90% completo"
Creando confianza y confianza
Otro beneficio que se gana al realizar entregas tempranas de trabajo de software y con frecuencia es que estamos contruyendo confianza, tanto entre el equipo y el cliente como dentro del mismo equipo. Al mostrar a lo clientes (y a nosotros mismos) que podemos entregar iteraciones de versiones, estamos haciendo la vida mucho más fácil para todo nuestro equipo.
El cliente tiene el control
Hay una diferencia clave en el rol y poder entre los desarrollos incrementales y el desarrollo tradicional de casacada del cliente. Pues, con el desarrollo incremental el cliente elige y busca las características principales. Del mismo modo, elige las características que puede eliminar, no disponibles para ser implementadas y que estan dentro del proyecto asignado en tiempo o presupuesto.
Las decisiones de los clientes son, seguros, influenciado por el costo de las caracteríticas, que por las estimaciones de los desarrolladores- incluyendo el costo de las demoras, construcción, orden , etc.
La capacidad del cliente en tomar decisiones en que se gasta sus dinero y cambiar su forma de mirar a los proyectos de software. Por último, el cliente tiene el control. Hable sobre cómo motivar a los clientes¡¡
Hay una diferencia clave en el rol y poder entre los desarrollos incrementales y el desarrollo tradicional de casacada del cliente. Pues, con el desarrollo incremental el cliente elige y busca las características principales. Del mismo modo, elige las características que puede eliminar, no disponibles para ser implementadas y que estan dentro del proyecto asignado en tiempo o presupuesto.
Las decisiones de los clientes son, seguros, influenciado por el costo de las caracteríticas, que por las estimaciones de los desarrolladores- incluyendo el costo de las demoras, construcción, orden , etc.
La capacidad del cliente en tomar decisiones en que se gasta sus dinero y cambiar su forma de mirar a los proyectos de software. Por último, el cliente tiene el control. Hable sobre cómo motivar a los clientes¡¡
La evolución de un trabajo compartido
Al fomentar una estrecha colaboración entre los testeadores , desarrolladores y clientes, somos efectivos facilitadores a una situación donde la información necesaria se obtiene tan pronto como sea posible -en todas las direcciones. Además, esta exposición es continúa en el equipo aumentando la eficiencia en la comunicación como el conocimiento entre los desarrolladores generando un lenguaje compartido. El desarrrollo de software es un negocio de personas y no debemos descuidarnos en ello.
Vamos a ver la posibilidad de usar test de aceptación usando como fundamento un lenguaje compartido incluyendo a cliente y al equipo de desarrollo y tester.
1.4.3 Test como un lenguaje compartido
Uno de los mayores problemas en el desarrollo de software es no tener claridad de los requerimientos o necesidades del cliente. Esto deja de ser un juego de niños para expresar y comunicar los requisitos de tal forma que ninguna información pierda la transmisión de la idea original. Algunos dicen a lo lejos que es imposible realizarlo. Despues de todo , no podemos leer la mente de nuestros clientes.
Este problema es evidente cuando usamos un medio de comunicación es por medio de una documentación escrita- por ejemplo, especificaciones de requerimientos- lo cual es lejos un medio perfecto para la transferencia y comprensión de la información. Si pudieramos ser capáz de trasnformar los requisitos en pruebas ejecutables y que verificaran si el sistema se ajusta a las aspectos y condiciones particulares, habría menos problemas con las ambiguedades y el espacio entre la interpretación y los desarrolladores. Esta es la premisa perfecta de los test como especificaciónes.
Test de Pruebas como especificaciones.
Los test como especificaicones provee una manera de de ver las pruebas como algo esencial que se derivan de los requisitos, por lo que en teoría, un sistema que pasa sus pruebas , se ajustan a la especificación.
De vez en cuando, obtenemos defectos a través de pruebas. Esto no es novedad para quienes hemos estado a lo menos en dos proyectos de software comercial. Esto se debe por no considerar todas las pruebas las pruebas necesarias. En parte , esto se debe a nuestra naturaleza humana y nuestra intuición engañosa, donde , sólo se resuleven algunas incidencia para ahorra tiempo.
Esto nos plantea la pregunta, ¿Estamos realmente usando los test como especificaciones , si los tests tienden a fugarse por otros caminos? Esto es realmente factible para el uso de los test como especificaciones, efectivamente redifiniendo el significado de los conceptos?. Usando test como especificaciones no es una bala de plata, pero tiene una serie de ventajas que valen la pena considerar.
- Más rápido a través de la automatización.
- Ejecución de pruebas más confiables.
- Menos pasos.
Aún en la transformación de requerimientos en los test , existen la posibilidad de errar. pero, la transferencia de conocimientos y la interpretación humana implica la ejecución de los test con menos cambios en los lugares donde se ha diseño.
Ejemplo de especificación.
Uno de los beneficios más notables del uso de pruebas como especificaciones, es el impulso de desarrollar pruebas típicas que empleen especificaciones no abstrata en escritura, es decir, en vez del tradicional "el sistema deberá calcular el impuesto de...." como patrón de los documentos de requerimientos, sino especificaciones como por ejemplo "para una suscrpción de 20 dólares con un tipo impositivo del 10%, el sistema carga un total de 22 dólares de la cuenta del usuario"
Este simple requerimientos, se diferencia entre el tradicional "el sistema debera..." y el ejemplo basado en versiones no tan significativas- después de todo , sabemos como calcular el impuesto como caso trivial, Sin embargo, los requerimientos para cumplir con el trabajo no suelen ser tan triviales, y el riesgo de mantenerlos es mucho más alto. Por ejemplo, la aplicación de impuesto múltiples para una operación determinada, puede ser que necesite emplear diferenctes reglas en diferentes lugares, que pueden ser aclarados a través de ejemplos concretos.
La especificaciones es un paso natural de nuestra intuición y hace más fácil relacionar los requerimientos para el mundo concreto en nuestro software. Las especificaciones también se pueden ver en TDD. Considerando que las pruebas de aceptación especifican el comportamiento deseado del sistema, los ejemplos y el comportamiento deseado especificado con las pruebas unitarias especifican acerca de la apliclación deseada y no de la funionalidad entregada.
Mayor calidad por dentro y fuera, mejor confianza en nuestro trabajo, y al cliente queda complacido frente a un software ajustado a sus necesidades. Después de todo, todo es posible. Luego haremos nuestra propia caminata o conversación pero, primero hablaremos de las herramientas a nuestra disposición.
1.5 Herramientas para el desarrollo de ejecución de test
Las herramientas son importantes. Sin herramientas como compliladores, editores, sistemas de explotación , desarrollo de software sería difícil comparádolo donde han llegado décadas y décadas de avances técnicos. Ahora vamos a tomar tres categorías fundamentales de herramientas y técnicas: un frameworks de testing unitarios, integración contínua con mecanismo de apoyo y, cobertura de código.
1.5.1.- Pruebas unitarias con xUnit
Hace años, Kent Beck creó un framework de pruebas unitarias para SmallTalk llamado SUnit (http://sunit.sf.net). Este framework ha sido la luz para circular dentro de la comunidad de desarrollo de software.Esta misma herramienta basada en SUnit - es llamada también JUnit, disponible en http:/www.junit.org/ . La familia de los frameworks de pruebas unitarias basados en los patrones encontrados en SUnit y JUnit es similar a xUnit. ¿Qué hacen exactamente?
¿Qué hace exactamente el framework de pruebas unitarias en el contexto de xUnit?, Significa que la librería ofrece apoyo para escribir código de pruebas unitarias, ejecutarlas sobre los resultados de prueba. En el caso de Junit, proporciona un conjunto de clases e interfaces para tareas comunes aserciones , y así sucesivamente. Para ejecutar los JUnit escritos en Junit, el proyectos provee de diferentes test runners- son clases que saben como coleccionar un ser de pruebas unitarias , los ejecuta , colecciona los resultados , y muestra el desarrollo gráficamente o resumen de resultado.
En este libro veremos JUnit y Java. De hecho usaremos varias ampliaciones de JUnit a medida que avanzamos en una prueba de manejo diferentes tipos de componentes. Si usted no está familiarizado con JUnit, por favor, refiérase a los apéndices de una introducción a esta pequeña y maravillosa herramienta. No demasiados inmersos en los detalles de JUnit, tenemos un par de categorías adicionales de las herramientas para ejecutar las pruebas de aceptación de TDD.
1.5.2 Framework para test de TDD de aceptación.
Aunque los frameworks de los escenarios de test unitarios, se ha desarrollado bajo el concepto de xUnit, no es tan homogéneo en el mundo de las pruebas de aceptación. La principal razón de esta diferencia es la idea de una prueba de manejo en el nivel funcional ya que es relativamente nuevo, y la ejecución iterativamente de las pruebas con herramientas de automatización no funcionan bien cuando no hay nada para grabar.
Otra cosa al pensar sobre la fragmentación del negocios es, el factor de dos sistemas rara vez tienen la mismas interfaces exacta. La excepción a la regla es la aplicación web, la cual puede ser accesadas con tecnologías estándar, como el protocolo HTTP y el lenguaje de tag HTML. Lo que es más importante que las tecnologías involucradas, son las herramientas destinadas a apoyar nuestro ineterés primordial con TDD de aceptación- cierra el negocio de colaboración.
Existen herramientas como FIT y FITnesse que son orientadas a tablas visuales que colaboran con los desarrolladores, testeadores y analistas de negocio no técnicos. Fit usa un formato tabular con una familia de herramientas , que permiten escribir pruebas ejecutables que representan pruebas como declaraciones. Una de las herramientas más conocidas de esta categoría es EXACTOR. A veces es sufiente para los fines de un proyecto dado utilizar un medio más técnicos, como un lenguaje de secuencias de comandos para describir pruebas. Es un framework para pruebas de aceptación , de fácil acceso, otra opción es manejar un framework de propia cosecha.
Vamos a ver más de cerca algunas de estas herramientas en la parte 3 al explorar la aceptación basado en pruebas en un mayor desarrollo. Por ahora , pasaremos a la siguiente herramienta relacionada que deben cubrir a los continuos servidores.
1.5.3.- Integración contínua y constructores.
Trabajar en un equipo que está en constante cambio en el código aqui y allá, crea una presión en los desarrolladores para integrar sus cambios significativos. algunos utilizados en entornos tradicionales. Los equipos que utilizan TDD emplean la por propiedad el código colectivo, lo que significa que todos estan autorizado para cambiar cualquier código base.
En la práctica, esto significa que mientras el equipo está refactorizando como parte de su ciclo de pruebas, habrá un flujo constante de pequeños cambios en el repositorio de código fuente. Con esto en mente, esperando a que dos días antes se chequen tus cambios e igualmente los requerimientos manualmente- esta es una actividad que no gusta mucho.
Todo esto nos lleva a adoptar un proceso sincronizado en nuestros cambios en el repositorio de fuentes con más frecuencia que antes. La alta frecuencia de integración
de los desarrollos, da un espacio a los desarrolladores en un repositorio centralizado, donde no solo cabe la integración de la fuente en la compilación sino también en la verificación de la fuente integrada mediante la ejecución de pruebas automatizadas.
Ventajas y Desventajas
Un patrón común con los equipos de aplicación contínua es ejecutar un subconjunto de todas las pruebas antes de comprobar en sus cambios y delegar en funcionamiento de la suite de pruebas (incluyendo la unidad, integración y pruebas funcionales) a un servidor dedicado a contruir, también conocido como una acumulación contínua con el servidor. En la figura 1.12 muestra una configuración básica con un servidor de integración contínua de votación para los cambios de el repositorios de código fuente.
En escencia , esta es una práctica que muchos equipos deciden hacer. Por un lado hacer correr las suit de test demora un varios minutos que esperar la barra verde, es decir que los test se hayan ejecutados sin problemas.
En el caso que los cambios puedan romper alguna prueba del desarrollador, no hay que ejecutarlos sin antes notificarlos al resto del equipo y verificar la base de código donde fué roto los cambios recientes.
Construir servidores con servicios varios
Afortunadamente usted no necesita escribir sus propias herramientas para ejecutar un servicios para lo construído, debido que existen productos de código abierto, así como existen productos comerciales que ofrecen funcionalidades necesarias. Algunos de los populares incluyen Cruise- Control (http://cruisecontrol.sf.net), hormiguero (htpp:/www.urbancode.com), Continuum (htpp://maven.apache.apache.org/continuum) y Bambú (htpp://www.atlassian.com/software/bamboo/)., y otros que estan apareciendo en el tiempo.
Si usted está interesado en aprender más sobre integración contínua y sus herramientas asociadas, consulte el artículo de Martin Fowler "Continua Integración" o James Costa ha hecho una gran escritura de la diferencia entre hacer la integración contínua y el uso de servidores de integración continúa.
1.5.4 Código de cobertura
Muchos desarrolladores están familiarizados con herramientas de análisis de código estático.Los desarrolladores en particular, podrían tener experiencia en ejecutar la herramienta PMD (http:/pmd.sf.net) para detectar anomalías en relación con el uso ilegal de determinadas construcciones o para calcular las mediciones de la complejidad. La mayor atención a las pruebas automatizadas y especialemnete , las pruebas unitarias , también se creado una serie de herramientas para medir la cobertura del código. en resúmen . la cobertura del código es una medida de cúanto findo ejercen nuestras pruebas automatizadas en el código de producción y sus declaraciones de código de fuente, ramas y expresiones.
El principal beneficio es la incorporación de medidas de cobertura de código basado enla constante prueba de nuestro software. Esto es especialmente útil cuando un equipo está empezando aescribir las pruebas unitarias o la adopción de TDD, porque ayuda a la búsqueda de ámbitos de la base de código.
¿Qué grado de cobertura debo apuntar?
Cuando nos planteamos el tema de cobertura , nos cuestionamos a qué altura debemos poner el listón de cobertura, si es de un 100%, 90% o un 80%?.
La respuesta es depende , de las tecnologías específicas , idiomas, herramientas en uso y frecuencia. Para Java y proyectos J2ee es una cobertura promedio de 85%.
No hay comentarios:
Publicar un comentario