Niveles de felicidad en el testing

En la lista de Agile Spain se está comentando un artículo muy interesante de UncleBob sobre sobre Scrum y TDD y donde Leo Antoli pregunta si se están dejando de lado las capacidades de TDD como técnica para dirigir el diseño de un sistema.

Mi opinión al respecto está en el hilo y no quería entrar demasiado en ella en este artículo. Básicamente es que veo dos líneas en TDD. Una es la centrada puramente en testing, donde gira todo en torno a JUnit y tener barras verdes, y que personalmente creo que no es aplicable a diseños complejos y serios (ojo que no digo que no se haga TDD, sino sólo que en ese contexto no me parece una técnica aplicable a a dirigir nuestros diseños) ya que tiende a la sobre-simplificación de los sistemas y a un microdiseño o microtesting.

Escribiendo micro-benchmarks con jmicrobench

Tal y como escribía hace unos días, mi opinión es que los microbenchmarks no son una técnica recomendada para sacar conclusiones sobre el rendimiento global de nuestros programas.

Sin embargo sí que existe una serie de circunstancias en las que es importante el conocer el rendimiento de tu lógica de negocio. Por ejemplo cuando estamos trabajando en sistemas que requieren procesar una gran cantidad de transacciones por segundo. Imaginaros quizás un sistema de pagos por Internet, o el software de una casa de apuestas, o la línea de almacén de un gran fabricante de lo que sea.

En estos casos no sólo es necesario el tener la confianza en que el software va a soportar el volumen esperado sino que es necesario garantizarlo. ¿Cómo lo podemos garantizar? Con tests. Pero hacer los tests puede ser complicado. Por eso se hacen útiles frameworks para la creación de microbenchmarks como jmicrobench del que nunca había oido hablar pero que en breve os contaré en otro post como he llegado a el.

jmicrobench es una extensión de jUnit que define un nuevo ejecutor de Tests: PerformanceTestRunner que se encarga de ejecutar nuestros tests y de calcular el número de operaciones por segundo que ejecuta, su media, e incluso de generar gráficas. Un test de rendimiento se crearía de la siguiente forma:

Creando mejores tests

Alfredo Casado ha publicado hace unos días en su blog un artículo muy recomendable donde comparte con todos una serie de consejos a la hora de crear mejores tets.

Alfredo nos recomienda tratar a nuestro código de tests como si fuese de producción y además explica una de las funcionalidades más interesantes de JUnit 4.7, que no conocía por cierto, que es la creación de reglas (Rules) que permiten extraer código común que se utiliza en todos los tests.

No cuento nada más. El que quiera saber más que lea su artículo: Escribiendo mejores tests.

Test funcionales para todos: Canoo WebTest + Grails.

Hace ya unos meses comentaba que Grails tenía sus cosas buenas y también sus cosas malas.

Pues bueno, el plugin de tests funcionales pasa a engrosar la lista de cosas que me gustan. Se trata de un plugin que integra Canoo WebTest, una fenomenal herramienta de testeo de la capa web.

Lo más importante que quiero destacar del artículo que estoy escribiendo es que no se limita a Grail. Este plugin simplemente se encarga de simular el acceso a páginas web y ejecutar un número de aserciones sobre las páginas. Los tests se escriben en Groovy y se necesita Grails para ejecutar, pero eso es todo. Es decir, podemos utilizar este sistema para testear cualquier aplicación web, ya esté hecha en Grails, en Java o en .NET. Y ya veréis que por lo sencillo que es, vale la pena.

Lo primero de todo es seguir las instrucciones del wiki, e instalar el plugin. Asumiendo que tenemos instalado Grails, tendríamos que:

• Crear el proyecto: grails create-app tests
• Instalar el plugin: grails install-plugin webtest
• Crear la carpeta de tests: grails create-webtest

Una vez hecho esto tendremos una estructura de directorios con la configuración de los tests, los reports y una carpeta "tests" donde se irán colocando los tests funcionales. Crear un tests es insultántemente sencillo, y treméndamente intuitivo. Tan sólo es cuestión de saber como trasladar el conjunto de tareas de WebTest a Groovy. Pero entre los ejemplos, y lo sencillo que es, pues no debería haber ningún problema.

Fijaros en el siguiente ejemplo de un test funcional que tenemos en Jobsket para comprobar que los perfiles de Linkedin se importan correctamente:

def testLinkedinUpload() {

invoke      '/login'
verifyText  'Entra en Jobsket'
setInputField(name:'login',value:"${user}")
setInputField(name:'password',value:"${password}")
clickButton 'Entra'

invoke '/upload/linkedin'

setInputField(name:'profile',value:'http://www.linkedin.com/in/mpermar')
setCheckbox(name:'legalAccepted')
clickButton '!Sube tu CV desde Linkedin!'

verifyText 'Tu CV'
}

¿Es necesario que explique algo del test? Nada de código Java, nada de XML, nada de scripting raro. No os exagero, hacer tests funcionales con Grails y WebTest es una gozada. El código es muy sencillo de leer, y además al ser Groovy sigues teniendo la potencia que te ofrece un lenguaje orientado a objetos y puedes agrupar funcionalidad común a los tests en otras clases. Pues por ejemplo agrupar la parte de login de ahí arriba en un método login que pondríamos en una clase padre. Es un ejemplo.

Quedaría simplemente ejecutar el test:

• grails run-webtest MiTest

Una vez se ejecutan los tests, los informes se pueden ver desde la web:



Y nada más. Simplemente resaltar lo comentado. Si estás haciendo un proyecto web, y buscas una herramienta para ejecutar tests funcionales, entonces Grails + Canoo WebTest es una opción muy recomendable. Además se integra muy bien con Hudson, pero eso lo dejo ya para otra entrada :)

Frameworks que espolean y ceden el paso

Ojeando las noticias de InfoQ he visto una entrevista a los creadores de TestNG: Cedric Beust y Hani Suleiman.

TestNG es uno de esos frameworks que ha cumplido su cometido. Bueno, realmente no lo ha cumplido en el sentido estricto de la palabra ya que estoy seguro que sus desarrolladores lo crearon para hacerse con el mercado del unit testing. Pero sin embargo, ha cumplido su cometido en el sentido de que gracias a él ahora JUnit es mucho mejor.

Cuando se lanzó TestNG, JUnit había estado varios años sin ninguna actualización, y las carencias eran realmente importantes. No había soporte de anotaciones, no se podían ignorar tests, el soporte de excepciones era realmente precario, y bueno, vamos, que la cosa podía ser mucho mejor de lo que era realmente. TestNG tuvo un enorme impacto en su momento, y ofrecía la funcionalidad que muchos desarrolladores estaban esperando.

Incluso en el 2005 tuve la suerte de hacer una entrevista a Cedric Beust acerca de dicho framework (la entrevista estaba originalmente en javahispano, pero es una pena con el cambio de web parece que mucho del contenido antiguo ya no está disponible; por suerte todavía está disponible en agile-spain).

El caso es que desde el 2006 el desarrollo en JUnit se agilizó de nuevo y la cantidad de funcionalidades que han añadido ha mejorado el producto considerablemente. JUnit 4.0 añadió muchas funcionalidades interesantes pero con JUnit 4.4 realmente han dado el empujón que hacía falta en parte gracias a integrar muchas contribuciones como el mecanismo de aserciones o las Theories.

La verdad es que me resultó curiosísimo que los creadores de TestNG lanzasen un libro a finales del 2007 sobre un framework aparentemente abandonado con los foros ya llenos de spam. Supongo que sería algo que tenían abierto desde mucho antes y que han querido terminar por el honorcillo y supongo que por sacar algún dinero. De todos modos en la entrevista de InfoQ, cuando le preguntan directamente a Cedric sobre el futuro de TestNG, la verdad es que evade la respuesta.

¿Será porque considera haber fracasado? Si es así, pues personalmente creo que se equivoca. Para mi TestNG ha cumplido su cometido y ha tenido éxito. Es cierto que yo ahora mismo no se lo recomiendo a nadie, sin embargo está clarísimo que si no hubiese sido por TestNG, ahora a lo mejor seguiríamos haciendo chapuzillas con JUnit 3.x.

Y es que a veces es necesario tener frameworks que obliguen a los demás a ponerse las pilas.

Bug Driven Development

Ayer leyendo el blog de Phil Haack me ha gustado mucho la respuesta imaginaria que le hace en su blog a un hipotético escéptico de toda metodología de testing y en la que se inventa el concepto de BDD:

I’m sorry, but I’m not a fan of Bug Driven Development. I think Test Driven Development is not without its challenges, but it’s a better alternative. Either you’re with us, or against us. Are you a bug lover? Bug Driven Development gives comfort to the bugs.

Yo no sería tan radical para decir que si no prácticas el Test Driven Development caerás en un proceso continuo de corrección de errores, pero lo que no cabe duda es que si no existe ningún proceso de calidad, si no existen unit tests, integration tests o una automatización mínima de los tests, se llega a un punto en el que el equipo de desarrollo entra en modo corrección de errores.

Quizás una de las peores consecuencias de esta BDD es que muchos de esos bugs, que no fueron testeados en su momento, ocasionarán cambios en el diseño y en la arquitectura del sistema, cambios que pueden requerir desde horas de código hasta muchos días. Y todo por no seguir un proceso de mínima prevención en un primer momento.

Al final esto de TDD y BDD no deja de recordarme en cierto modo a la medicina preventiva (TDD) y la medicina curativa (BDD).

El rol de build engineer

Una de las posiciones que más hemos intentado presionar donde trabajo para que se contratase es la de release/build engineer.

No cabe duda que hoy en día construir software es más complejo (no necesariamente más difícil) que hace años. La cantidad de diferentes sistemas que intervienen en el funcionamiento de una aplicación hace que crear una release sea mucho más complicado que hace años donde casi sólo había que preocuparse por crear un fichero ejecutable para su correspondiente plataforma.

Hoy por hoy nos encontramos que cualquier mínimo software involucrará aplicaciones de escritorio, applets o RIAs, contenedores web, servidores de aplicaciones, sistemas de mensajería, interfaces o servidores de terceros, etc. Asimismo, la integración continua (incluso aunque nos ponga en evidencia) se ha convertido en una práctica fundamental a la hora de lanzar software a tiempo. Sin embargo, está claro que a medida que el software se hace cada vez más y más complejo el mantener este proceso de integración continua se hace más complicado. Y es que hay que tener en cuenta que el proceso de integración continua no se limita únicamente a compilar el código fuente y asegurarse de que no se ha roto la build , si no que es necesario construir un sistema "vivo" que nuestro departamento de QA pueda utilizar para asegurarse de que realmente no se ha roto nada.

Para intentar solucionar este problema se introduce el rol de build/release engineer. Hoy por hoy si se busca en los portales de empleo se encuentran ofertas de empresas que buscan cubrir este tipo de vacante, aunque es cierto que tampoco son demasiadas. Por ejemplo hoy he estado buscando en las ofertas de Irlanda y sólo he encontrado tres o cuatro en el portal que suelo seguir.

La verdad es que por experiencia propia puedo decir que aunque el rol está justificado lo cierto es que es complicado encontrar a alguien que se quiera dedicar exclusivamente a mantener la salud del sistema de automatización de una empresa, por mucho que este rol te permita aprender como funcionan internamente muchos sistemas. Al fin y al cabo, quién quiere pasarse meses pelando con scripts y ficheros XML, ¿no?

Por lo tanto, en el caso de reconocer el valor de build engineer y no poder contratar a uno, ¿qué se puede hacer? Básicamente se me ocurren dos soluciones:

• Promocionar a alguien de QA: Normalmente (al menos aquí) los testers suelen ser graduates o personas con conocimientos informáticos pero que nunca se han dedicado a programar o que ni siquiera han estudiado realmente informática. Muchas de estas personas son realmente buenos en lo que hacen y llegan a tener un conocimiento global del funcionamiento del sistema mucho mejor que muchos desarrolladores.
  
  Algunos de estos testers con el tiempo van ganando experiencia y conocimientos que les permitirían pasar a ejercer un rol de build engineer, que a fin de cuentas está directamente relacionado con todo el proceso de QA, así que podría verse como un tipo de promoción natural.


• Asignar el rol de build engineer a todo el equipo: Para mi es importante resaltar aquí lo de "todo el equipo". Ya que todos sabemos lo que va a pasar si un desarrollador se dedica a configurar la build el sólo, es decir, que se convertirá de manera no-oficial en el build engineer, y que siempre que pase algo acudiremos a él a ver si lo puede solucionar.
  
  Rotando el rol de build-engineer entre los diferentes miembros del equipo, por ejemplo haciendo que cada semana uno ejerza ese papel, se consigue que todo el mundo acabe por tener un conocimiento de la build y que se mejore también el conocimiento global de como funciona el sistema. Al principio puede hacerse tedioso y engorroso, por eso de que todos tenemos muchas cosas que hacer para andar aprendiendo todos lo mismo, pero con el tiempo y cuando los errores aparezcan todo el grupo habrá adquirido el conocimiento para solucionar los problemas de automatización y no se dependerá del release engineer que vuelve dentro de un mes y se ha ido de vacaciones.

Por cierto, que si os lo estáis preguntando, pues nosotros por ahora nos hemos quedado en un termino medio. Cuando llegué no había nada de nada, pasados unos meses conseguimos un build engineer, pero con el tiempo lo perdimos, y ahora, pues bueno, como al final nuestra automatización ha llegado a niveles bastante avanzados y es bastante compleja pues requiere mucha dedicación, así que hay un equipo digamos de "gestión de procesos" que se dedica a controlarla, siendo algunos de los miembros de este equipo también desarrolladores. Es decir, que en lugar de involucrar a todos los desarrolladores lo que puede ser un poco utópico pues se escogen a tres o cuatro y se les asigna la responsabilidad de estar pendientes de eso como parte de su tiempo.

Eclipse y su infraestructura de testing

Hace tiempo hablaba del Eclipse Way y de como me fascina el proceso de desarrollo que siguen.

Repasando un ppoco las charlas de este año de la EclipseCon 2007 (ya ha llovido) me he encontrado con una bastante interesante de Sonia Dimitrov y Kim Moir donde hablaron sobre todo el proceso de QA que se sigue en Eclipse.



Se extraen varias cosas interesantes:

• Tienen el rol de build engineer para proteger a los desarrolladores del proceso de build (este rol merece un post en si mismo).
• 176.000 tests en 33.000 JUnit tests ejecutándose en cinco build machines con máquinas virtuales 1.4, 1.5 y 1.6.
• 469 tests de rendimiento con 2345 tests que se ejecutan en cinco máquinas diferentes. Se ejecutan sólo unos cuantos días debido a que lleva unas 10 horas ejecutar los tests y procesar los resultados.
• Para asegurarse la validez de los tests de rendimiento utilizan imágenes ghost que instalan justo antes de lanzar los tests.
• Tienen un conjunto de tests de limpieza. Chequean que todo esté correcto: javadocs, licencias, políticas de código, etc.
• Los desarrolladores escriben test unitarios, pero el código de los tests se mantiene separado en un CVS propio.
• Los resultados de los tests de rendimiento se almacenan en una base de datos dedicada.
• Para detectar fallos tienen un parser que analiza la salida de los tests y en caso de errores genera reportes y los envia a una lista de correo.
• La mayor parte de los errores que obtienen no se deben en realidad a errores en el código sino a problemas con las máquinas, poco espacio en disco, actualizaciones de software, antivirus, etc.

No sé que os parece, pero a mi me ha sorprendido especialmente toda la infraestructura dedicada al testing, incluido el dedicar un CVS específicamente para el almacenar el código de los tests. Está claro que toda esta infraestructura y este proceso tan elaborado debe tener algo que ver con la capacidad para estar lanzando versiones sin retraso durante cinco años.

Probando la eficiencia de los tests unitarios

Via Navegapolis descubro una nueva utilidad para mejorar la eficiencia del proceso de testing. Se trata de Jumble, una herramienta que permite medir la efectividad de los tests unitarios que hayamos escrito.

La idea es clara. Seguro que como yo, algunos habréis tenido la sensación después de terminar los unit tests de que quizás no sean tan completos como os gustaría, e incluso cuando la herramienta de cobertura de código (code coverage) te dice que la cobertura es buena, tu tienes esa sensación de que hay maneras de entrar en el programa que no has cubierto con unit tests.

Lo que hace Jumble es mutar el código de tus clases y después ejecutar los unit tests. Como ha mutado las clases, lo que Jumble espera es que los unit tests sean capaces de detectar esa mutación y alerten de que la entrada es inválida, y por lo tanto fallen. En caso de que los unit tests no fallen pues es probable que ese caso en concreto no haya sido cubierto.

Las mutaciones son de lo más diversas, por ejemplo cambiar sentencias condicionales (e.g. x > y pasa a ser !(x>y)) o por ejemplo cambiar el valor de las constantes definidas en el código, o modificar operaciones aritméticas. Para mutar el código Jumble utiliza la librería BCEL y modifica el bytecode en tiempo de ejecución.

El concepto me ha parecido realmente interesante. Me parece una aplicación bastante inteligente a la modificación de código fuente. En fin, que en el video sobre Model Based Testing que nos recomienda Juan Palacio hablan un poco sobre ello y muestran algún ejemplo.

EclEmma, de lo mejor en cuanto a cobertura de código

Hacía tiempo que no me encontraba con un plug-in de Eclipse que me haya cautivado más. Se trata de EclEmma, nominado a mejor herramienta de desarrollo Open Source basada en Eclipse del 2007; y sólo puedo decir que realmente... se lo merece. Ha sido instalarla y caer enamorado.

Y es que no requiere ningún esfuerzo por parte del desarrollador. Nada de tener que ejecutar ant, o maven, o tener que abrir ficheros HTML con tus informes de cobertura. Nada. Simplemente ejecuta tus unit tests, y ahí tienes toda la información de cobertura. Y lo mejor de todo es que te colorea temporalmente el código marcándote las partes que han sido cubiertas y las partes que no lo han sido.

Como bien dicen en su página principal: Fast develop/test cycle, Rich coverage analysis, y Non-invasive:. Y encima, la instalación tan cómoda como actualizar desde el update site y reiniciar. Hasta casi estoy pensando que tengo ganas de volver a trabajar para sentir esa sensación de placebo que da el subir en el nivel de cobertura... es broma :D

Como hacer rápidamente pruebas unitarias y de integración con Jackrabbit

Bueno, uno de mis propósitos de año nuevo, o más bien de Enero, es volver a darle un empujón a mi blog en inglés. Así que iré poniendo aquí las entradas que pongo en el otro. Si alguién realmente necesita alguna traducción sólo tiene que pedirla.

Y es que yo tengo serios problemas con lo de bloggear en inglés o en español. Cuando estaba en España, era como si tuviese la necesidad de bloggear en inglés, y ahora me pasa exactamente lo contrario. Pero lo cierto es que me encuentro con que bloggear también en inglés es muy importante en estos momentos porque de algún modo te sirve como carta de presentación para hacer contactos, entrar en comunidades, etc. Pero por otra parte, no puedo escribir nada sobre mi trabajo, ya que sería problemático. Bueno, en fin, un lio.

Aquí queda la susodicha entrada sobre Jackrabbit e unit testing:
Como hacer rápidamente pruebas unitarias y de integración con Jackrabbit

Tests en el water

En el trabajo en el que estoy en este momento te das realmente cuenta de lo difícil que es inculcar una cultura de tests dentro de proyectos grandes. Estás constantemente explicando que hacer tests es bueno, preparas herramientas para hacer tests de integración de componentes y de integración global de manera sencilla, rellenas wikis, confluences, y herramientas diversas con información, fuerzas que los tests rompan la build, o instals herramientas de cobertura. No importa. Siempre hay gente que no hace código y partes de los programas que fallan a última hora y que descubres que no tienen tests.

Y es que acostumbrarse a la cultura de pruebas es complicado. De hecho yo soy el primero en haberme hecho el vago en el pasado :) Y parece que las compañías grandes como Google no se libran de los problemas, por mucho que sus acciones suban en bolsa. Hoy he descubierto que han hecho publico algo llamado Test on the Toilet, que consiste en una serie de hojas con consejos sobre la importancia de realizar tess, como afrontarlos, como conseguir una buena covertura, etc. Las hojas se colocan en el water de modo que todo el mundo las pueda leer en lugar de tener que llevarse el periódico para leer los deportes. Aquí una prueba.

Una idea simpática y revolucionaria. No sé por qué pero me da la impresión de que puede ser muy efectiva.

Integración continua y avergonzamiento público

Una de las medidas que Mike Clark promovía en el libro de cabecera Pragmatic Project Automation es la de mostrar el resultado de las diferentes build de la manera más visible que se pueda. El objetivo está claro, saber lo más pronto posible cuando y por qué se ha producido un evento que ha roto el proceso de build de la aplicación.

En mi compañía se ha ido un poco más allá, y como aliciente adicional se ha creado una lista de "Top Build Breakers". Además el manager de producto recibe un bonito email semanal con estadísticas tan jugosas como cuantas veces se ha roto el proceso de build, quienes son los que más lo rompe, cuanto se tarda en solucionar un problema, y cosillas así.

Aunque los desarrolladores noveles son los que más han protestado con la medida, por considerarla intimidatoria y como un punto importante de presión, lo cierto es que medidas así aseguran a mantener alto el estado de salud del código, al menos en cuanto a compilación y pruebas unitarias. Pasados ya más de tres meses desde la aplicación de la medida, la productividad ha aumentado enormemente, y sobre todo el tiempo que la base de código permanece en un estado inconsistente ha decrementado radicalmente. Hace meses el código podía estar días en estado inconsistente (valga como defensa que hablo de varios cientos de proyectos), y ahora mismo pasa no más de unos cuantos minutos. La gente es mucho más cuidadosa con el código que se sube al repositorio y con los tests unitarios que se crean.

Por lo tanto, que nadie se asuste por aplicar o por sufrir estas medidas, ya que la experiencia dice que al final es un beneficio para todos. Por cierto. Sí, he roto alguna vez la build. Pero que conste que no salgo en la lista de ganadores :-)

Pruebas proactivas, tests de integración y equipos de tests

Hay un dicho que suele decir que un poco de prevención vale más que un mucho de curación. Personalmente, este dicho lo aplicaría al mundo de las pruebas de software para crear el concepto de pruebas proactivas.

¿Qué es una prueba proactiva? : Una prueba proactiva es aquella cualquier prueba que no tendríamos obligatoriamente que realizar pero que nos permite adelantarnos a los acontecimientos. La principal ventaja de las pruebas proactivas es que nos permiten crear software mucho más sólido previniendo problemas no esperados desde un punto de vista unitario, integracional o funcional.

Ejemplos de pruebas no proactivas serían aquellas que es obligatorio realizar para mantener un software saludable, como los tests unitarios, tests de integración o tests funcionales.

Ejemplos de pruebas proactivas pueden ser los tests de rendimiento, tests de carga y tests de integración.

Ahora bien, si miráis la lista veréis que los tests de integración están tanto en la lista de pruebas proactivas como en la lista de pruebas obligatorias. ¿Por qué? El problema es que los tests de integración yacen en el limbo de los tests.

En una empresa normalmente tenemos diferentes equipos de desarrollo que trabajan con diferentes componentes. Los desarrolladores de estos equipos tienen la responsabilidad de ofrecer componentes lo suficientemente probados a través de tests unitarios. Por otra parte, hay muchas empresas que tienen un equipo completo de testers que se encargarán de realizar todas las pruebas funcionales de cara al usuario final.

El punto más peliagudo es el de los tests de integración. Los tests de integración se encargan de comprobar que los diferentes componentes de nuestro sistema funcionan como es debido, y que interactuan como se espera dentro de sistemas que imitan al entorno de producción que nos vamos a encontrar. Nótese que la palabra integrar aquí adquiere un significado algo ambiguo y se refiere tanto a integrar dos piezas de software que se deben comunicar entre sí, como a integrar esas piezas de software en un entorno de ejecución determinado.

¿Quién hace y cómo se hacen estas pruebas de integración? Sin lugar a dudas, lo ideal es mantener un equipo de desarrollo de tests de integración que se encargue de desplegar los componentes en un sistema similar al de producción y de probar la integración de estos componentes. Aquí es donde entra la proactividad. Estos equipos de producción deben realizar el test del producto olvidándose del usuario final. Esto permite eliminar la dependencia de los casos de uso y alcanzar una cobertura mucho mayor en nuestro software, ya que incluso aunque estuviésemos cubriendo el 100% de los casos de uso definidos en la arquitectura, la realidad es que probablemente los casos de uso no estan cubriendo el 100% de las acciones que nuestros usuarios realizarán.

El problema de mantener los tests de integración orientados al usuario final es que uno no puede realmente estar seguro de que su software es sólido y fiable. Es muy común por ejemplo en los entornos de tests el realizar las pruebas de integración utilizando robots web o robots de GUI, que se encargan de simular el comportamiento del usuario final. ¿Es esto una prueba de integración real entre componentes? No. Esto son pruebas funcionales, y nunca se deberían tratar como pruebas de integración. El problema es que se tratan como tales debido a falta de presupuesto para contratar equipos de test de integración, a falta de conocimiento por parte de los equipos de testing funcional o a falta de tiempo por parte de los desarrolladores para asumir semejante carga.

En resúmen, ponga un equipo de ejecución y creación de tests de integración en su vida y será mucho más feliz :-)