Tiempo de lectura: 5 minutos

Esta entrada del blog la dedicaré exclusivamente a conceptos relacionados con el testing. Será una entrada que se irá actualizando constantemente con nuevos contenidos.

System Under Test (SUT)

Parte del sistema que se está testeando.  Dependiendo del tipo de test que se esté realizando, se tendrá distinta granularidad.

Depended On Component (DOC)

Es cualquier entidad que permite a un System Under Test cumplir su objetivo. Ej: Una clase email que permite establecer el destinatario, subject y contenido. Además, recibe un objeto ServerEmail que permite su envío. Esa clase ‘externa’ sería lo que llamamos DOC.

Prueba Unitaria o Test Unitario

Un test unitario es una prueba de código que verifica el correcto funcionamiento de una unidad de código, es decir, de una única clase. Tienes las siguientes características:

  • Un test unitarios nos permite saber si nuestra clase funciona correctamente, tal como se espera.
  • Se centra exclusivamente en probar el funcionamiento de la clase y sus colaboradores (DOC) serán remplazados con test dobles.
  • Se ejecutan con frecuencia.
  • Su ejecución es muy rápida.

Pruebas de Integración o Integrations Test

Son pruebas de código que se centran en verificar el funcionamiento correcto de la integración entre distintos módulos de la aplicación. Tienes las siguientes características.

  • Son pruebas más lentas que las unitarias.
  • No suele integrarse con la parte de interfaz de usuario
  • Suelen tener requisitos previos: preparar base de datos externas, servicios, API, etc…

Un ejemplo de prueba de integración sería el envío de emails. Se probaría el modulo para la creación del email y el módulo de envíos del emails.

Pruebas Ent-To-End

Este tipo de pruebas se encargan de verificar que el código realizado funciona desde un punto de vista del cliente. Ej: Funcionalidad de un Login. Tiene las siguientes característica.

  • Prueba múltiples módulos. Ej:Login. Probaría la interfaz de usuario, clases internas, petición a la API, etc.
  • No suelen usarse test dobles. Se intentan hacer pruebas los más real posible.
  • Son las pruebas más costosas y requieren mucho tiempo en su ejecución.

Cada una de las funcionalidades de la aplicación puede tener uno o varios test end-to-end. Ej: Login con datos correctos y su acceso a la pantalla privada o Login con datos incorrectos y su redirección a una pantalla de error.

Suelen ser los test usados para la metodología BDD.

Desarrollo Guiado por Pruebas o Test Driven Development (TDD)

Es una técnica de desarrollo incluida dentro de la metodología Extreme Programming y consiste en desarrollar antes la prueba unitaria que la funcionalidad. Su pilares son:

  • Todo el código tiene pruebas unitarias.
  • Implementar sólo el código necesario para hacer que la prueba o el test pase (YAGNI: You aren`t gonna need it. No desarrolles funcionalidades que no vas a necesitar ahora).
  • Gracias a la fase de ‘refactoring’ ayuda a mantener el código limpio.

Pruebas de Caja Blanca o White Box Test

Son pruebas que se centran especialmente en las funciones internas de nuestra aplicación. Ej: pruebas unitarias.

Pruebas de Caja Negra o Black Box Test

Son pruebas que se centran especialmente en las entradas y las salidas y no en cómo se hace. Ej: Tengo una máquina para cambiar billetes por monedas. Un usuario introduce en la máquina un billete y le devuelve la misma cantidad de dinero en monedas. Sólo nos centramos en la entrada y salida y no en cómo lo hace.

Sería el estudio de un módulo o un componente de nuestra aplicación. Cómo interactúan con otros módulos, etc. 

Primero la prueba o Test First

Está directamente relacionado con TDD. Primero se realiza la prueba y luego el código que pase esa prueba. Uso de hacer la prueba primero no es conveniente en todos los casos, por ejemplo, si nunca hemos trabajado con esta metodología se recomienda hacer el test después del código para ir cogiendo experiencia. También cuando se trabaja con ‘legacy code‘ el test se hace después del código para refactorizar posteriormente con seguridad.

Primero el código después la prueba o Test Last

Esta metodología consiste en escribir pruebas después del código. No es muy recomendada por:

  • Se suelen desarrollar las pruebas basadas en el código que existe y no en la funcionalidad requerida. 
  • La prueba que se desarrolla está acoplada al código que existe.
  • Se suelen hacer pruebas basadas en las condiciones de la función existente.

Como se ha visto en ‘test first’ en algunas ocasiones puede ser útil esta técnica.

Dummy

Un dummy es un tipo de ‘test doble’ y es un objeto que se usa para poder crear otros objetos. Ejemplo: