la jerga del testing

Hace ya unos cuantos post que estoy hablando sobre testing, PHPUnit, TDD y demás. Llegados a este punto tengo nos cuantos conceptos en la cabeza y no quiero que se me olviden así que he decidido escribirlos todos en un post.

Tiempo atrás escribí otro post sobre la jerga de los informáticos, así que ahora creo que es el momento de escribir “LA JERGA DEL TESTING”

Así que vamos a por ello:

Setup / Test / Assert / tear down

Toda prueba automática se compone de 4 partes:

Setup: Todo lo que se necesita antes de ejecutar la prueba.
Test: Es el código que queremos probar.
Assert: Es la parte donde comparamos el resultado del código con alguna condición esperada.
Teardown: Limpiamos todo lo que hallamos utilizado durante la prueba para dejar el software que estamos probando en un estado estable,tal y como estaba antes del setup.

SUT

Sistem Under Test, es el software que queremos probar, ya sea una aplicación web, una app móvil o una aplicación de escritorio. Básicamente es todo lo que queremos probar.

Testing Framework

Es una “aplicación” que está diseñada específicamente para probar código en un lenguaje específico. Históricamente estos framworks se llaman xUnit, donde x es el lenguaje que queremos probar. Por ejemplo tenemos PHPUnit para PHP, Junit para Java, NUnit para .Net…

Test Case

Es la unidad más pequeña de las pruebas. Representa un caso de prueba individual.

Vamos un poco mejor, un caso de prueba es un conjunto de métodos de prueba relacionados. El concepto es algo ambiguo, ya que un test case es un caso de prueba, un conjunto de valores con los que probar el código.

Test Method

Un método de test es la parte más pequeña de una test suite. Consta de las 4 partes anteriormente descritas: setup/ test/assert/teardown. Basicamente es la que hace el trabajo.

DOC – Dependent-On Component.

Este es uno de los términos más confusos. Representa todas las otras clases que componentes que el SUT necesita para funcionar correctamente. Además el DOC debe proporcionar los métodos necesarios para poder observarlo y probarlo. Conceptos como mocking and test doubles están estrechamente relacionados con DOC.

La pirámide del testing

La pirámide representa las tres capas principales del testing. La interfaz de usuario, el Servicio y la unidad.

Interfaz de usuario representa el nivel más elevado en la pirámide: Cuando se realizan test sobre la interfaz de usuario, la aplicación se prueba como un todo. Esta capa debe tener pocas pruebas, ya que es la que probablemente sufra más cambios.

Capa de Servicio aquí se engloban diferentes tipos de prueba. Sobre todo aquí testearemos la comunicación entre los diferentes módulos y el funcionamiento de la API externa. Estas pruebas por lo general se usan probando arias partes de la aplicación por lo que son bastante lentas. Se deben ejecutar frecuentemente, por ejemplo después de cada commit o una vez al día, para tener un ciclo de inspección y entrega continua en nuestro ciclo de desarrollo software.

Capa Unitaria, es la capa más grande de la pirámide, aquí probamos nuestro código completamente aislado. Estas pruebas deben ser muy rápidas y deben ejecutarse con mucha frecuencia, por ejemplo TDD (test Driven Development es un buen ejemplo de como aprovechar este tipo de pruebas.

Desgranado la pirámide

Si queremos ahondar un poco más en el testing, podemos desglosar la pirámide anterior en

Prueba Unitaria: Es la unidad más pequeña que se puede probar en un lenguaje de programación. Por ejemplo en programación orientada a objetos podría ser una clase / objeto.

Pruebas de componentes: Prueban un módulo completo, o parte del mismo, sirven para comprobar que todo el conjunto del código correspondiente a una clase funciona correctamente. También pueden ser un requisito de negocio.

Prueba de integración Sirven para comprobar cómo se integran varios módulos entre sí. Verifica si las APIS internas de cada módulo son compatibles entre sí.

Pruebas API En programación orientada a objetos las API se definen como los métodos públicos de las clases.

Pruebas de GUI Probar si un botón es verde o rojo o tiene 50 pixeles es inútil, las pruebas de GUI sirven para comprobar que la conexión entre la parte gráfica y la lógica de negocio funciona, por ello estas pruebas son difíciles de automatizar.

Pruebas de aceptación

Se tratan de las pruebas más controvertidas. Dependiendo de la bibliografía pueden ser: pruebas de clientes, pruebas de aceptación, pruebas funcionales…

Normalmente son pruebas que parten de la GUI, pero ese cambio va a tocar varios puntos del sistema como a lógica de negocio o la GUI.

Integración continua

Cuando se trabaja en un proyecto se hace necesaria una batería de test automáticos, además si estas pruebas están organizadas e manera eficiente mucho mejor. Así pues

La integración continua es una práctica de desarrollo de software donde los miembros de un equipo integran su trabajo con frecuencia, por lo general cada se integra por lo menos diariamente. Cada integración es verificada por un constructor automático que incluye test para detectar errores de integración lo más rápidamente posible. – Martin Fowler

Basándonos en esta definición, el proceso de integración continua hará el trabajo de correr nuestras pruebas sin la intervención humana. Por ejemplo, cada vez se hace un commit se da lugar a lugar ejecutar una serie de test obtener un email, verde o rojo, dependiendo del resultado, en tan sólo unos minutos. Si el correo es de color verde, el producto es teóricamente entregable.

Entrega continua

No está relacionada con las pruebas, pero si con la integración continua. La entrega continua automatiza todos los pasos desde el código al producto terminado. La entrega continua lleva un paso más allá la Integración continua.

Pruebas manuales

Hay muchas partes del código que son muy difíciles de probar, más que de probar, de automatizar. Por eso es necesario realizar una serie de pruebas manuales para estar seguro de que el software que se entrega está correcto.