java - unitaria - Usando JUnit como un marco de prueba de aceptación

prueba unitaria con junit

Question

OK, entonces trabajo para una compañía que ha adoptado abiertamente prácticas ágiles para el desarrollo en los últimos años. Nuestras pruebas unitarias y la calidad del código están mejorando. Un área en la que aún estamos trabajando es encontrar lo que mejor nos funciona en el campo de las pruebas de aceptación automatizadas. Queremos tomar nuestras historias de usuario bien formadas y usarlas para dirigir el código de una manera basada en pruebas. Esto también nos dará pruebas de nivel de aceptación para cada historia de usuario que luego podemos automatizar.

Hasta la fecha, hemos probado Fit, Fitnesse y Selenium. Cada uno tiene sus ventajas, pero también hemos tenido problemas reales con ellos. Con Fit and Fitnesse, no podemos evitar sentir que se complican demasiado y hemos tenido muchos problemas técnicos al usarlas. El negocio no ha comprado completamente con estas herramientas y no está particularmente interesado en mantener los scripts todo el tiempo (y no son grandes fanáticos del estilo de la mesa). El selenio es realmente bueno, pero lento y se basa en datos y recursos en tiempo real.

Un enfoque que ahora estamos considerando es el uso del marco JUnit para proporcionar una funcionalidad similar. En lugar de probar solo una pequeña unidad de trabajo con JUnit, ¿por qué no usarla para escribir una prueba (con el marco de JUnit) para cubrir una franja de nivel de aceptación de la aplicación? Por ejemplo, tome una nueva historia ("Como usuario me gustaría ver los detalles básicos de mi política ...") y escriba una prueba en JUnit que comience a ejecutar el código de la aplicación en el punto de entrada del enlace de detalles de la política, pero cubre todo el código. y la lógica desciende hasta la capa de acceso a los datos y vuelve al punto de reenvío a la página siguiente de la aplicación, afirmando qué datos debería ver el usuario en esa página.

Esto me parece tener las siguientes ventajas:

• Simplicidad (no se requieren marcos adicionales)
• Cero esfuerzo por integrarse con nuestro servidor de compilación de integración continua (ya que ya maneja nuestras pruebas JUnit)
• El conjunto de habilidades completo ya está presente en el equipo (es solo una prueba de JUnit después de todo)

Y las desventajas son:

• Menos participación del cliente (aunque están muy involucrados en escribir las historias de usuario en primer lugar desde las que se escribirán las pruebas de aceptación)
• Tal vez sea más difícil de entender (o hacer entender) la historia del usuario y los criterios de aceptación en una clase de JUnit en comparación con una especificación de texto libre como Fit o Fitnesse

Entonces, mi pregunta es realmente, ¿alguna vez has probado este método? ¿Alguna vez lo has considerado? ¿Cuáles son tus pensamientos? ¿Qué te gusta y te disgusta de este enfoque? Por último, solo menciona marcos alternativos si puedes decir por qué te gustan o no te gustan más que este enfoque.

Answer 1

Algunas recomendaciones si sigues ese camino:

• Ponga sus pruebas de aceptación en otro proyecto, ya que probablemente se ejecutarán más lentamente y tendrán más dependencias que sus pruebas habituales
• Cree constructores (tal vez utilizando una interfaz fluida ) para configurar su modelo en dispositivos de prueba, porque encontrará que configurar los objetos necesarios para su prueba será la parte más aburrida y difícil de mantener.
• Eche un vistazo a Groovy y al Spock Framework : es compatible con JUnit, pero le proporciona un DSL agradable para que sus pruebas sean legibles.

Answer 2

En mi humilde opinión no es una buena idea. Aparte de las 2 desventajas que mencionó, ¿qué le parece la gran cantidad de esfuerzo requerido para crear un marco de prueba de aceptación que se ocupará de todo tipo de escenarios web / UI / pegamento que pueda tener? Su punto "Simplicidad (no se requieren marcos adicionales)" es incorrecto, ya que su organización tendría que invertir en la creación de un marco más elaborado sobre JUnit. Puede ser más que JUnit.

Answer 3

Es perfectamente válido usar JUnit para escribir pruebas de aceptación. JUnit es solo un marco de ejecución de prueba, es completamente irrelevante si realmente está escribiendo pruebas unitarias con él, pruebas de componentes, pruebas de integración o pruebas de aceptación. Como el usuario1704737 ya dijo, es importante que tenga un DSL legible para escribir sus pruebas.

Para escribir tus pruebas en JUnit te sugiero que pruebes a JGiven . Es un marco liviano para facilitar la escritura de pruebas de aceptación en la notación dada cuando se usa en Java plano. Utiliza JUnit (o TestNG) como ejecutor de prueba, de modo que puede integrarse fácilmente en las infraestructuras de prueba existentes. También obtiene informes HTML para sus pruebas de aceptación que puede mostrar a las empresas para validar las pruebas según los requisitos.

Descargo de responsabilidad: soy el autor de JGiven

Answer 4

Mi experiencia usando JUnit para un framework de Pruebas de Aceptación.

Nuestra compañía hizo algo muy similar cuando empezamos con FitNesse y luego fuimos a JUnit. Lo hicimos principalmente porque FitNesse ya estaba sobre Java, por lo que cambiar a JUnit fue fácil. FitNesse parecía no satisfacer nuestras necesidades.

Aquí están mis pros y contras de usar JUnit:

Pros:

• JUnit tiene mucha flexibilidad (porque es Java), por lo que es relativamente fácil crear un lenguaje interno específico del dominio [Fowler]. El DSL se puede modificar para que sea fácil de leer / escribir para expertos en dominios (no ingenieros de software).
• Ya que es JUnit, puedes usar Eclipse como un IDE, lo que te da autocompletado, verificación de sintaxis, depuración, etc.
• Específicamente para nuestra aplicación, tenemos una interfaz CORBA para la interfaz de usuario. Java puede usar fácilmente esta interfaz CORBA también.

Contras:

• La gente oye JUnit y piensa en la prueba unitaria. Esto se vuelve confuso cuando las personas comienzan a referirse a las pruebas de aceptación como "pruebas JUnit".
• Para proporcionar un entorno de prueba simplificado, debe dedicar algo de tiempo a ampliar el marco y desarrollar su DSL.

Entonces, en resumen, JUnit funciona bien para las Pruebas de Aceptación si está dispuesto a dedicar el tiempo necesario para extenderlo a su propio entorno de prueba específico de dominio. De lo contrario, creo que buscaría algo más fuera de la caja.

Answer 5

Pruebe robotframework (www.robotframework.org), lo he estado usando durante años, Pekka Klarck de Helsinki lo desarrolló (Nokia Siemens Networks lo respalda desde el principio, ahora también es de código abierto).

robotframework utiliza casos de prueba de formato tabular, que admiten HTML, CSV o texto sin formato (escrito en cierta gramática). Tiene un mecanismo de biblioteca, que permite importar funciones de Selenium. Puede escribir una biblioteca para robotframework en Python o Java.

Por supuesto, para el JUnit as Acceptance Test Framework, puedes hacerlo, pero no vale la pena hacerlo. Las pruebas de nivel superior deberían depender mucho menos de la implementación interna de un software, mientras que la prueba de aceptación de escritura utilizando JUnit (que es un marco de prueba de unidad), introdujo muchas dependencias en sus llamadas de funciones internas, por ejemplo. Lo que será un gran dolor de cabeza mientras haya algún cambio en el diseño del software, lo que no se verá afectado en una prueba de alto nivel y ya está.

Answer 6

Usted mencionó algunos puntos positivos sobre los pros y los contras. Puedo añadir:

Ventajas: Me gusta la idea de poder probar todo sin tener que tener una base de datos, un servidor web. Esto ayuda enormemente en la comprensión del código y en la refactorización.

Desventajas:

El código JUnit será complejo y difícil de mantener. Tendrá que reproducir todas las interacciones entre el código y el usuario dentro de la prueba Junit, que se vuelve muy compleja rápidamente. Si todo lo que está haciendo es probar un único punto de entrada, esto podría funcionar, pero si está probando varias pantallas (un asistente o algo así), entonces puede volverse frágil e inmanejable rápidamente. El problema en mi experiencia es casi siempre el código de plomería entre páginas, o el código de configuración requerido para una página.

Otra cosa a considerar es la flexibilidad de lo que estás tratando de hacer. Con Fitnesse, es bastante fácil agregar otra prueba si descubre un error. De hecho, esta es la idea detrás de Fitnesse: el ''usuario'' puede agregar otra prueba sin tener que cambiar el código. No subestimes el valor de esto.

Así que sugeriría dos cosas:

1) Inténtalo. Toma una historia de usuario (no demasiado compleja, no demasiado simple) y hazlo en JUnit. Compara lo que has hecho con el Selenium / Fitnesse, etc., y ve si vale la pena. Vea si 1. realmente encuentra errores, 2. produce un código frágil y difícil de administrar.

2) ¿Podría utilizar los datos creados por Fitnesse como entrada para sus pruebas de JUnit (eliminando así la necesidad de un servidor web, etc.)? Posiblemente podría leer los datos y llamar a los métodos en las clases de Java directamente. De nuevo, puede tener problemas con la configuración y el código de la base de datos.

Answer 7

Negocios y UAT
La mayoría de las veces, los negocios perderán el interés en cualquier herramienta de prueba, tarde o temprano. Después de todo, no son evaluadores de negocios, por lo que no se comprometen mucho a escribir / mantener los scripts de prueba. Son negocios, quieren hacer negocios. Desde su punto de vista, los probadores / desarrolladores / otros responsables de TI son responsables de entregarles software de cierta calidad.
Incluso si Agile es tu camino, y obtienes cierto nivel de compromiso por parte de las empresas, no esperes que se comporten como probadores con cada sprint / iteración o lo que sea que tengas. Realmente no es su trabajo.
Una digresión: las Pruebas de aceptación del usuario son pruebas manuales ejecutadas por el (los) usuario (s), por lo que él (ellos) puede decir es el producto lo que pidió.
Entonces, cuando la característica (o conjunto de características) esté lista, haga una presentación para los negocios, déjelos jugar, déjelos decir que es lo que necesitan. No los obligue a comprobar esta característica con cada iteración.

Ahora volvamos a sus pruebas de aceptación. Siempre que tenga una historia del cliente que hacer, implemente pruebas en su infraestructura de prueba. Lo escribes, lo ejecutas, lo mantienes. Puede ser conveniente realizar una prueba de desarrollo de características y unidades con ADD / BDD / TDD o como se quiera llamar. Debería ser obvio que esta (s) prueba (s) contribuyen a su conjunto de pruebas de regresión en las próximas iteraciones.

Por lo tanto, mi punto de vista es que a las empresas no les interesa escribir / mantener las pruebas, especialmente cuando el conjunto de características crece. No luches con eso, adáptate a ello. Permítales que realicen las Pruebas de aceptación del usuario (manual) al final de la iteración para las nuevas funciones. Por su propio bien, cree pruebas para las características que desean tener. Crear pruebas de aceptación de características para cada característica. Deja que esas pruebas se conviertan en tu traje de prueba de regresión. Acepta que t es tu responsabilidad mantenerlo.

Marco de pruebas de aceptación
JUnit, ¿eh? Luego intente con WatiJ para web y Abbot para escritorio. Tenga en cuenta que esas pruebas no serán simples Pruebas unitarias. Desea algo que pruebe las características de la aplicación real, desea que el script de prueba ejecute un escenario / proceso empresarial específico. Esto significa que debe abordar esas pruebas como la aplicación de escritura que están probando: DRY, KISS, YAGNI, Design Patterns: todo se aplica. Al final, será un software de escritura, que simplemente pasa a probar otro software que usted escribe.

¿Serán estas pruebas grandes y complejas con este enfoque? Bueno, más grande y más complicado que las pruebas unitarias. Pero no están probando una sola unidad sino toda la aplicación. Además, serán mucho más simples y pequeñas que las aplicaciones que estás escribiendo en primer lugar.

¿Serás abeja escribiendo el framework de pruebas? Si quiere tener éxito con este enfoque, entonces sí, estará escribiendo el marco de prueba: colección de clases de prueba y clases de ayudante que tienen algún conocimiento sobre su aplicación implementada. Pero no estarás extendiendo JUnit. JUnit aquí es solo una API que utiliza en su marco.