The Agile Way: ¿Pruebas de integración frente a pruebas funcionales o ambas?

Question

Trabajo en una oficina que hace Agile desde hace un tiempo. Utilizamos Scrum para la gestión de proyectos y combinamos las prácticas de ingeniería de XP. Funciona bien y constantemente estamos aprendiendo lecciones y refinando nuestro proceso.

me gustaría informarle sobre nuestras prácticas habituales para las pruebas y obtener información sobre cómo esto podría ser mejorado:

TDD: primera línea de defensa Estamos bastante religiosa de las pruebas unitarias y yo diría nuestros desarrolladores también tienen la experiencia suficiente para escribir pruebas exhaustivas y aislar siempre el SUT con burlas.

Pruebas de integración Para nuestro uso, las pruebas de integración son básicamente las mismas que las pruebas unitarias simplemente sin utilizar los simulacros. Esto tiende a detectar algunos problemas que pasaron por las pruebas unitarias. Estas pruebas tienden a ser difíciles de leer, ya que generalmente implican mucho o trabajan en las secciones before_each y after_each del marco de especificaciones, ya que el sistema debe alcanzar a menudo un cierto estado para que las pruebas sean significativas.

Prueba funcional Normalmente hacemos esto de una manera estructurada, pero manual. Hemos jugado con Selenium y Windmill, que son geniales, pero para nosotros al menos todavía no están completos.

Me gustaría escuchar cómo alguien más está haciendo cosas. ¿Crees que si las pruebas de integración o las pruebas funcionales se llevan a cabo lo suficientemente bien, el otro puede descartarse?

Answer 1

unidad, la integración y las pruebas funcionales, aunque el ejercicio del mismo código, están atacando desde diferentes perspectivas.Son esas perspectivas las que marcan la diferencia, si dejaras caer un tipo de prueba entonces algo podría funcionar desde ese ángulo.

Además, las pruebas unitarias no se tratan realmente de probar el código, especialmente si está practicando TDD. El proceso de TDD helps you design your code better, solo obtienes la ventaja añadida de un conjunto de pruebas al final del mismo.

No ha mencionado si tiene un servidor de integración continua ejecutándose. Recomiendo encarecidamente configurar uno (Hudson es fácil de configurar). Entonces puede hacer que su integración y pruebas funcionales corran contra cada check in del código.

Answer 2

Pruebas unitarias, pruebas de integración y pruebas funcionales todas sirven para diferentes propósitos. No debe descartar uno solo porque los demás se ejecutan con un alto nivel de confiabilidad.

Answer 3

Yo diría (y esto es sólo una cuestión de opinión) que sus pruebas funcionales son sus verdaderas pruebas. Es decir, esas pruebas que realmente simulan el uso real de su aplicación. Por esta razón, nunca te deshagas de ellos, pase lo que pase.

Parece que tiene un sistema decente funcionando. Consérvelo todo si no tienes nada que perder.

Answer 4

Hemos tenido la experiencia de que un conjunto sólido de pruebas de selenio realmente resume realmente lo que el cliente espera de la calidad. Así que, en esencia, hemos tenido esta discusión: si escribir pruebas de selenio fuera tan fácil como escribir pruebas unitarias, deberíamos centrarnos menos en las pruebas unitarias.

Y si hay es un error en algún lugar que no tiene ninguna consecuencia en la aplicación, ¿a quién le importa? Pero siempre están los problemas que rodean las complejidades de la vida real; ¿Estás seguro de que tus pruebas funcionales están capturando los escenarios correctos? Puede haber complejidades subyacentes causadas por otros sistemas que no son directamente visibles en el comportamiento de la aplicación.

En realidad, escribir pruebas de selenio (usando un lenguaje de programación apropiado, no selenese) hace ser realmente simple y divertido una vez que se explora los problemas iniciales. Pero no estamos dispuestos a renunciar a nuestras pruebas unitarias del todo todavía ....

Answer 5

Tiendo a no separar varios sabores de prueba en TDD. Para mí, TDD es desarrollo basado en pruebas, no desarrollo basado en pruebas unitarias. Entonces mi práctica de TDD combina pruebas unitarias, pruebas de integración, pruebas funcionales y de aceptación. Esto hace que algunos componentes sean cubiertos por ciertos tipos de pruebas y que otros componentes sean cubiertos por otros tipos de pruebas de una manera muy pragmática. He preguntado question acerca de la relevancia de esta práctica y la respuesta corta fue que en la práctica la separación es entre pruebas rápidas/simples ejecutadas automáticamente en cada compilación y las pruebas lentas/complejas se ejecutan con menos frecuencia.

Answer 6

Mi empresa realiza pruebas funcionales, pero no unidades o pruebas de integración. Estoy tratando de alentarlos a adoptarlos, los veo como un mejor diseño y una indicación más rápida de que todo está bien. ¿Necesita pruebas unitarias si realiza pruebas funcionales?

Answer 7

En mi cliente actual, realmente no separamos entre pruebas unitarias y pruebas de integración. Las entidades comerciales son tan dependientes de la capa de datos subyacente (utilizando un marco ORM propio) que, en efecto, tenemos pocas o verdaderas pruebas unitarias.

El servidor de compilación está configurado con integración continua (CI) en Team Build y para evitar que se atasque demasiado con pruebas lentas (el conjunto de pruebas completo tarda más de una hora en ejecutarse en el servidor) hemos separado las pruebas en pruebas "lentas" que se ejecutan dos veces al día y pruebas "rápidas" que se ejecutan como parte de una integración continua. Al establecer un atributo en el método de prueba, el servidor de compilación puede distinguir entre los dos.

En general, las pruebas "lentas" son las que requieren acceso a datos, uso de servicios web o similares. Estas se considerarían pruebas de integración o pruebas funcionales por convención común. Algunos ejemplos son: pruebas CRUD, pruebas de reglas de validación comercial que necesitan un conjunto de objetos para trabajar, etc.

Las pruebas "rápidas" son más parecidas a pruebas unitarias, donde puede aislar razonablemente el estado y el comportamiento de un solo objeto para la prueba.

Considero que cualquier prueba que se ejecute en décimas de segundo o menos es "rápida". Cualquier otra cosa es lenta y probablemente no debería ejecutarse como parte de CI.

Estoy de acuerdo en que no debe preocuparse demasiado por el "sabor" de la prueba que usa como parte del desarrollo (expresando criterios de aceptación ya que las pruebas son la excepción, por supuesto). El desarrollador individual debe usar su criterio para decidir qué tipo de pruebas se adaptan mejor a su código. Insistir en pruebas unitarias para una entidad comercial podría no revelar las fallas de una prueba CRUD, y así sucesivamente ...

Answer 8

Me gusta mucho el concepto Gojko Adzic de una "prueba de ahorro de cara" como una forma de determinar lo que prueba a través de la IU: http://gojko.net/2007/09/25/effective-user-interface-testing/

Answer 9

Debe hacer todas ellas porque la unidad, la integración y las pruebas funcionales sirven para diferentes propósitos.
pertenece a mí un punto importante es que la prueba forma de escritura es muy importante y TDD no es lo suficientemente, BDD (comportamiento impulsado el desarrollo) dan un buen enfoque ...

Answer 10

Yo comparo las pruebas unitarias como asegurarse de que las palabras en un párrafo están deletreadas correctamente. Las pruebas funcionales son como asegurarse de que el párrafo tenga sentido y fluya dentro del documento en el que se encuentra.