Cómo utilizar pruebas unitarias y funcionales durante el desarrollo

Este enfoque requiere que escriba pruebas unitarias para cada función recién agregada y mantenga estas pruebas. No puedo agregar ningún código al módulo sin pasar las pruebas unitarias. A medida que crece la base del código, estas pruebas permiten a los desarrolladores integrar los cambios de manera informada. Al principio, pensé que estas pruebas unitarias eran suficientes para abordar la situación general y que no había necesidad de involucrar pruebas funcionales. Ah, mal de nuevo. Las pruebas funcionales y las pruebas unitarias son dos cosas completamente diferentes. Me tomó mucho tiempo comprender la diferencia entre los dos y cómo combinarlos para mejorar el proceso de desarrollo. Este artículo explora las diferencias entre las pruebas unitarias y las pruebas funcionales, y cómo puede aprovecharlas en sus procesos de desarrollo y pruebas de desarrollo diarios. Como desarrollador, las pruebas son tan importantes que debe dedicar casi todo su tiempo a probarlas. . No es necesario dividirlo simplemente en una etapa específica del proceso de desarrollo. Obviamente, no debería ser la última tarea que complete antes de entregar el sistema a su cliente. ¿Pero cómo saber cuándo termina? ¿O cómo saber si corregir un pequeño error interrumpe la funcionalidad principal del sistema? ¿O podría el sistema evolucionar hacia algo más allá de la imaginación actual? Las pruebas, tanto unitarias como funcionales, deben ser parte del proceso de desarrollo. Las pruebas unitarias deben ser la parte central de la escritura de su código, especialmente cuando está trabajando en un proyecto y el tiempo ajustado limita el progreso de su desarrollo, y también desea que se lleve a cabo de manera controlable y ordenada. Espero que las pruebas también sean una parte importante de la escritura de pruebas antes de escribir el código. Un conjunto adecuado de pruebas unitarias debe tener las siguientes funciones: Explicar el mejor diseño aplicable posible Proporcionar el mejor formato para la documentación de la clase Determinar cuándo está completa una clase Incrementar la confianza del desarrollador en el código Esta es la base para una refactorización rápida Se incluye naturalmente en el diseño del sistema Documentación requerida para las pruebas unitarias. Vuelva a leerlo y verá que es el santo grial del proceso de desarrollo de software, donde la documentación evoluciona a medida que cambia el sistema. Es mucho mejor proporcionar documentación completa para cada clase que proporcionarle una serie de marcos de uso o una serie de entradas controlables. De esta forma, el documento de diseño irá actualizándose en cualquier momento a medida que se vayan superando paso a paso las pruebas unitarias. Debe completar el proceso de escritura de pruebas antes de escribir código. Hacerlo proporcionará una solución de diseño para las clases involucradas en la prueba y lo obligará a concentrarse en bloques de código más pequeños. Este ejercicio también facilitará la solución de diseño. No se puede intentar comprender la situación futura e implementar funciones innecesarias. Las pruebas de escritura también te darán una idea de cuándo terminará la clase. Se puede decir que cuando pasan todas las pruebas, la tarea está completa. Finalmente, las pruebas unitarias le proporcionarán evidencia de mayor nivel, lo que definitivamente satisfará a los desarrolladores. Si ejecuta pruebas unitarias mientras cambia el código, notará inmediatamente cuando rompa algo. Las pruebas funcionales son incluso más importantes que las pruebas unitarias porque indican que su sistema está listo para su lanzamiento. Las pruebas funcionales pondrán su sistema de trabajo en un estado utilizable. Un conjunto de pruebas funcionales aplicables debe tener las siguientes funciones: captar eficazmente las necesidades del usuario y proporcionar a los miembros del equipo del proyecto (incluidos usuarios y desarrolladores) la base para que el sistema enfrente estas necesidades. Las pruebas funcionales deben captar eficazmente las necesidades del usuario. Los desarrolladores tradicionales descubren sus necesidades en el proceso de uso. Normalmente, las personas aceptan utilizar proyectos de proyecto y dedican un tiempo considerable a personalizarlos. Cuando terminan, lo único que les queda es un montón de papel de desecho. Las pruebas funcionales son similares al caso de los proyectos de uso autoejecutables. La programación extrema puede ilustrar este concepto. El término XP es una descripción de las futuras habilidades de comunicación que se producirán entre usuarios y desarrolladores. Las pruebas funcionales también son el resultado de esta comunicación. Y sin pruebas funcionales, este argumento no se establecería. Las pruebas funcionales llenan el vacío entre las pruebas unitarias y la base del código enviado al equipo del proyecto. Las pruebas unitarias perderán muchos errores. Le brinda todas las partes válidas del código que necesita y le brinda el sistema completo que necesita. Las pruebas funcionales pueden exponer problemas que las pruebas unitarias no detectaron. Una serie de pruebas funcionales automatizadas y mantenibles aún pasarán desapercibidas, pero al menos serán mucho más útiles que las pruebas unitarias más completas de forma aislada. Pruebas unitarias versus pruebas funcionales Las pruebas unitarias les dicen a los desarrolladores que el código hace que las cosas funcionen correctamente, mientras que las pruebas funcionales le dicen al desarrollador que el código funciona correctamente.

Pruebas unitarias Las pruebas unitarias se escriben desde la perspectiva del desarrollador. Garantizan que cada método específico de una clase realice con éxito un conjunto específico de tareas. Cada prueba garantiza que, dada una entrada conocida, se obtenga el resultado esperado. Escribir un conjunto de pruebas unitarias automatizadas y mantenibles sin un marco de pruebas es casi imposible. Antes de comenzar, elija un marco con el que esté de acuerdo el equipo del proyecto. Sigue aplicándolo y te gustará. En la página de introducción a Extreme Programming (consulte la sección Recursos), hay muchos marcos de pruebas unitarias adecuados. Lo que me gusta usar es Juint para probar el código Java.

Pruebas funcionales Las pruebas funcionales se escriben desde la perspectiva del usuario. Estas pruebas garantizan que el sistema funcione como esperan los usuarios. Muchas veces, desarrollar un sistema completo es más como construir un edificio. Por supuesto, esta metáfora no es del todo apropiada, pero podemos ampliarla para comprender la diferencia entre pruebas unitarias y pruebas funcionales. Las pruebas unitarias son similares a un inspector de edificios que inspecciona el sitio de construcción de una casa. Se centra en los diferentes sistemas del interior de la casa, cimentación, diseño arquitectónico, electrificación, líneas verticales, etc. Inspecciona una parte de la casa para asegurarse de que esté en condiciones seguras y funcionando correctamente, es decir, directamente según el código de la casa. Las pruebas funcionales en este escenario son análogas a las de un propietario de casa que inspecciona el mismo sitio de construcción. Lo que esperaba era que los sistemas internos de la casa funcionaran correctamente y que el inspector de viviendas cumpliera con sus funciones. El dueño de la casa mira cómo sería vivir en una casa así. Prestó atención a cómo se veía la casa, que las diferentes habitaciones tuvieran el espacio adecuado, que la casa se adaptara a las necesidades de la familia y que las ventanas fueran exactamente donde recibirían la mejor luz. El propietario de la casa realiza una prueba funcional de la casa desde la perspectiva del usuario. El inspector de viviendas ejecuta las pruebas unitarias y se pone en la piel del constructor. Al igual que las pruebas unitarias, escribir un conjunto de pruebas funcionales automatizadas y mantenibles sin un marco de pruebas es casi imposible. Junit hace un gran trabajo con las pruebas unitarias; sin embargo, fracasa al intentar escribir pruebas funcionales. Junit no es equivalente a pruebas funcionales. Ya existen productos que cumplen esta función, pero todavía tengo que verlos utilizados en el proceso de desarrollo de productos. Si no puede encontrar un marco de prueba, tendrá que crear uno usted mismo. No importa cuán inteligentes seamos al configurar un proyecto o cuán flexible sea el sistema que construyamos, si nuestro producto no funciona, estamos perdiendo el tiempo. La conclusión es que las pruebas funcionales son la parte más importante del proceso de desarrollo. Dado que ambos tipos de pruebas son necesarias, necesitarás pautas para redactarlas. Cómo escribir pruebas unitarias
Es fácil emocionarse cuando empiezas a escribir pruebas unitarias. La forma más sencilla de comenzar es crear pruebas unitarias para código nuevo. Crear pruebas unitarias para código existente es una forma más difícil de comenzar, pero es factible. ) Comience con un código nuevo y, una vez que se acostumbre, siga releyendo el código existente y creando un conjunto de pruebas para él. Como se mencionó anteriormente, debes escribir pruebas unitarias antes de escribir el código que deseas probar. ¿Cómo se escriben pruebas para algo que aún no existe? ¡Buena pregunta! Dominar esta habilidad requiere un 90% de inteligencia y un 10% de habilidad. Lo que quiero decir es que simplemente finges que estás escribiendo exámenes para clases existentes. A continuación, haz el trabajo de escritura. Inicialmente, cometerás muchos errores de sintaxis, pero déjalo así, ignóralo. Luego realice pruebas unitarias, corrija los errores de sintaxis (es decir, use solo su propia interfaz de prueba definida para implementar la clase) y pruebe nuevamente. Repita este proceso, escribiendo cada vez suficiente código para corregir los errores y probando hasta que desaparezcan. El código está realmente completo cuando pasan todas las pruebas unitarias. En términos generales, sus clases deben estar abiertas a pruebas unitarias. Sin embargo, los métodos con funcionalidad sencilla, como los métodos de lectura y escritura Getting y Setting en el lenguaje Java, no requieren pruebas unitarias a menos que se realicen de una manera "especial". La siguiente guía es escribir pruebas unitarias cuando sienta la necesidad de comentar ciertas características en su código. Si usted es como muchos programadores y odia escribir comentarios para su código, las pruebas unitarias son una excelente manera de documentar las características de su código.

Empaquetar pruebas unitarias con las clases relacionadas que se están probando. (Esta organización permite que cada prueba unitaria tenga acceso directo a los métodos y parámetros que están empaquetados y protegidos en la clase). Evite el uso de objetos de dominio en pruebas unitarias. Los objetos de dominio son objetos específicos de una aplicación. Por ejemplo, una aplicación de hoja de cálculo tiene un objeto de libro, que es un objeto de dominio. Si una de sus clases ya conoce los objetos de dominio, es bueno utilizar estos objetos en sus pruebas. Pero si tu clase no involucra estos objetos, no permitas que se mezclen en la prueba. De no hacerlo, se reutilizará el código empaquetado. A menudo, las clases creadas para un proyecto también se pueden usar en otros proyectos, por lo que es posible reutilizar estas clases directamente. Pero si las pruebas para estas clases también se utilizan para otros objetos del proyecto, hacer que las pruebas sean efectivas llevará mucho tiempo y, por lo general, las pruebas se descartan o se reescriben. Se beneficiará de algunos de los consejos anteriores, pero lo más importante es que si no lo hace, nunca tendrá una comprensión completa y profunda de las pruebas unitarias. Ejecute pruebas antes y tenga evidencia completa en el código durante todo el proceso. A medida que avanza el proyecto, siempre puedes agregar más funciones. La ejecución de las pruebas le recordará si la implementación de la característica recién agregada romperá algo que ya tiene. Una vez que haya dominado el arte de escribir pruebas unitarias, deberá volver a leer el código existente. De hecho, codificarlos puede ser un desafío. Pero nunca pruebes por probar. Se puede decir que escribir pruebas es algo urgente, especialmente cuando descubre que necesita modificar una clase que no tiene un buen programa de prueba, ese es el momento adecuado para agregar pruebas. Como es habitual, las pruebas unitarias deben tener características para cada método de la clase. Una de las formas más sencillas de implementar pruebas es prestar atención a los comentarios del código durante las pruebas. En las pruebas unitarias, no se puede omitir ningún comentario. Al comienzo de describir el método de prueba, se deben agregar una gran cantidad de comentarios a la prueba unitaria. Cómo escribir pruebas funcionales Por muy importantes que sean las pruebas funcionales, también tienen la reputación de ser el feo hijastro del proceso de desarrollo. En la mayoría de los proyectos, las pruebas funcionales las realiza un grupo de trabajo independiente. Por lo general, requiere que un grupo de personas cooperen entre sí en el sistema para garantizar el correcto funcionamiento del proceso. Esta visión común y este enfoque de formación de equipos es muy estúpido. Las pruebas funcionales son similares a las pruebas unitarias. Debe escribir pruebas tan pronto como codifique un producto que tenga la participación del usuario (por ejemplo, un cuadro de diálogo), pero debe hacerlo antes de escribir el código. Una vez que comience una nueva tarea, describa claramente el contenido de la tarea en el marco de las pruebas funcionales. Las pruebas unitarias se realizan a medida que agrega código nuevo y el desarrollo continúa avanzando. Cuando todas las pruebas unitarias pasan, se realiza la prueba funcional inicial para determinar si el proyecto puede pasar o necesita ser modificado. Idealmente, el concepto de equipo de pruebas funcionales no debería existir. Los desarrolladores deberían trabajar con los usuarios para escribir pruebas funcionales. Después de que el sistema pase una serie de pruebas unitarias, los miembros del equipo responsables de las pruebas funcionales cambiarán los parámetros de la prueba preliminar y luego realizarán pruebas funcionales del sistema. La línea entre las pruebas unitarias y las pruebas funcionales
En general, es difícil trazar una línea clara entre las pruebas unitarias y las pruebas funcionales. Para ser honesto, nunca supe dónde debería trazarse esta línea. Al escribir pruebas unitarias, utilizo los siguientes métodos para determinar si la prueba unitaria se ha convertido en una prueba funcional:
Si la prueba unitaria trasciende los límites entre clases, puede convertirse en una prueba funcional
Si la prueba unitaria se convierte muy compleja, puede convertirse en una prueba funcional
Si la prueba unitaria se vuelve muy frágil (es decir, se ha convertido en una prueba, pero cambia pasivamente porque necesita atender los cambios de las diferentes necesidades de los usuarios), puede convertirse en una prueba funcional
Si la prueba unitaria es más difícil de escribir que el código que debe probarse, puede convertirse en una prueba funcional. Tenga en cuenta que la afirmación "puede convertirse en una prueba funcional" no es un estándar estricto aquí. . Existe una línea divisoria entre las pruebas unitarias y las pruebas funcionales, pero hay que decidir dónde se encuentra. Cuanto más fluidas se ejecuten las pruebas unitarias, más obvia será la transición entre pruebas específicas. Conclusión Las pruebas unitarias se escriben desde la perspectiva del desarrollador y se centran en las características de la clase que se está probando.

Al escribir pruebas unitarias, utilice las siguientes pautas: Escriba pruebas unitarias antes de probar el código de la clase. Tenga anotaciones del código en las pruebas unitarias. Pruebe todas las utilidades que realizan una función específica (es decir, obtener y configurar en el lenguaje Java diferentes métodos). para lectura y escritura, a menos que completen las funciones Obtención y Configuración de una manera especial) empaquete todos los proyectos de prueba con la clase bajo prueba y asígnelos al paquete del módulo. Proteja los derechos de acceso de los miembros y evite el uso de ciertos objetos en pruebas unitarias. Las pruebas también deben escribirse desde la perspectiva del usuario y centrarse en las funciones del sistema que le interesan. Elija un marco de pruebas funcionales adecuado o desarrolle uno y utilice estas pruebas funcionales para formular lo que quieren los usuarios. De esta manera, los evaluadores funcionales pueden obtener una herramienta automatizada y tener un buen punto de partida para acostumbrarse a la herramienta. Haga de las pruebas unitarias y funcionales una parte central del proceso de desarrollo. Al hacer esto, se asegurará de que el sistema esté funcionando correctamente. De lo contrario, es posible que no pueda garantizar que el sistema esté funcionando correctamente. Puede que las pruebas no sean divertidas, pero participar en pruebas unitarias y funcionales hace que el proceso de desarrollo sea más divertido. El recurso "Improving the Development Process with Ant and JUnit" (Development Works, diciembre de 2000) revela los beneficios de las pruebas unitarias, especialmente cuando se utilizan Ant y Junit. Comience a comprender los métodos de programación extrema. Descargue varios marcos de prueba unitaria desde la página web de programación extrema.