> For the complete documentation index, see [llms.txt](https://elguerre.gitbook.io/de0an/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://elguerre.gitbook.io/de0an/capitulo-6-la-construccion.-testeando-desde-el-principio/introduccion.md).

# Introducción

#### Capítulo 6 - La construcción: Testeando desde el principio

*Ahora que ya tenemos una parte de nuestro desarrollo listo, no podemos continuar sin antes tener a punto los procesos de reparación, detecciones de fallos y mejoras.*

*Durante este capítulo entenderemos todas las ventajas de detectar a tiempo cualquier fallo en nuestra aplicación. Repasaremos todos los conceptos y herramientas relacionadas con las pruebas y finalmente, entenderemos la importancia de las mismas gracias al ahorro de tiempo, costes y calidad, así como evitar algún que otro dolor de cabeza. Continuaremos configurando nuestra **build** nocturna y crearemos una de integración continua e incluso la configuraremos para la ejecución de pruebas automáticas y de interfaz de usuario.*

*Las pruebas, son una parte fundamental dentro del proceso de desarrollo de aplicaciones y definen la calidad, así pues, sin ellas, no debemos continuar.*

***

#### Introducción

Una alta calidad en el código supone un esfuerzo extra. Por el contrario, ahorra tiempo y dinero detectando cualquier fallo desde el momento en que comenzamos a desarrollar. Es decir, gracias a las pruebas: unitarias, integradas o funcionales, de carga etc., ahorraremos dinero, tiempo, y por supuesto, conseguiremos una gran calidad.

Es cierto que, en muchas ocasiones, el pensar en la codificación de las pruebas supone una tarea monótona, pesada e incluso se llega a aplazar. Pensamos que no se trata de algo prioritario, sin embargo, desde el momento en que comenzamos a desarrollar estamos expuestos a equivocarnos y cualquier modificación implica posibles fallos. Los cuales, en el momento en el que se producen son detectados con facilidad, por lo que a medida que avanzamos, la dificultad de detectarlos y pasarlos por alto, aumenta.

En las siguientes viñetas podemos ver un par de paradojas que hacen referencia a nuestro día a día en lo que a la detección y solución de bugs/errores de código se refiere.

| ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-aa20a9432a3f8c59129604e685670633f8d08496%2Fimage1.jpg?alt=media) | ![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-05503e0c6f417a764452a9e6bf1b71db72eac208%2Fimage2.jpg?alt=media) |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

**Figura 01.- Paradojas sobre la solución de bug**

Si ya sabemos que nuestro día a día es este, ¿Por qué seguir haciéndolo? Para conocer un poco más la importancia de las pruebas, veamos la siguiente gráfica.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-c3fefe9a5bfd68f29d017585b06c238c59e6ab23%2Fimage3.png?alt=media)

**Figura 02.- Costes de corrección de defectos en las distintas fases del desarrollo**

Según el Instituto de Ciencias de Sistemas de IBM, el coste de corregir un error descubierto después de la liberación de un producto es cuatro o cinco veces mayor que uno descubierto durante el diseño, y hasta 100 veces más que uno identificado en la fase de mantenimiento. Esto significa que no todos los defectos se encuentran en la fase de codificación/implementación, sino que desde que comenzamos a recoger requisitos estamos expuestos a producirlos. En resumen, cuanto antes los detectemos y corrijamos menor será el coste y, por consiguiente, menor el tiempo dedicado.

¿Significa lo anterior que si creamos más pruebas la aplicación tendrá menos defectos/bugs? La respuesta es, no. Todos ellos no pertenecen a la fase de codificación y aun siendo así, el esfuerzo por intentar detectarlos todos podría suponer un coste muy elevado.

Seguir profundizando en este tema puede llevarnos muchos capítulos e incluso un libro dedicado exclusivamente a ello, y tampoco es el objetivo particular de este libro. Si bien es cierto, y será donde nos centremos, tenemos que saber que el esfuerzo necesario para la creación de todas estas pruebas dependerá de varios factores:

* Alcance. Requisitos necesarios para completar la aplicación.
* Tiempo. Duración para completar la aplicación.
* Coste/precio. Dinero y recursos a dedicar a la aplicación.

Estos tres factores forman un triángulo equilátero denominado Triángulo de Hierro (o *Iron Triangle*). Tres vértices iguales que siempre tenemos que mantener para conseguir la calidad más apropiada. Cualquier modificación de uno de ellos supone una modificación en alguno de los otros dos.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-13d4b576fb1a279c33c3ded43f0a4e55cfd8c38b%2Fimage4.png?alt=media)

**Figura 03.- Triángulo Calidad, Coste, Tiempo**

Ejemplos:

* Un incremento en la calidad a un coste bajo supone un incremento del tiempo.
* Un incremento en la calidad en tiempo reducido, supone un incremento del precio/coste.
* Un bajo coste en tiempo reducido, implica una pérdida en la calidad.

Este triángulo podemos relacionarlo a su vez con dos cualidades muy importantes: la **Eficacia** y la **Eficiencia**, de manera que, aunque terminemos nuestra aplicación cubriendo el alcance completo de la misma, deberíamos conseguirlo en el menor tiempo posible y con el menor coste. Por supuesto, siempre con la calidad esperada.

{% hint style="info" %}
**Nota**: Las pruebas, minimizan el número de defectos y proporcionan un código robusto, flexible y más fácil de mantener, incluso el código de las propias pruebas. Priorizaremos la creación de éstas intentando que cubran aquellas partes de código que sean propensas a cambios, aquellas que tengan dependencias de otras, las que sean compartidas, etc. Todas estas características nos harán obtener la eficiencia (coste y tiempo), deseada.
{% endhint %}

Sabemos que testear desde el principio no es fácil. Requiere disciplina, constancia y, sobre todo, la convicción de que estamos invirtiendo en algo que nos devolverá con creces el esfuerzo. En los primeros compases del desarrollo, cuando apenas tenemos unas pocas pantallas y todo parece funcionar correctamente, resulta tentador posponer las pruebas para "más adelante". Sin embargo, ese "más adelante" suele llegar acompañado de una base de código más grande, más dependencias y más riesgo de que un cambio aparentemente inocuo provoque un fallo inesperado.

Por eso, en este capítulo apostaremos por incorporar las pruebas como parte natural del proceso de construcción. No como una tarea adicional que hacemos al final, sino como un compañero de viaje que nos acompaña desde el primer momento. Al terminar, comprobaremos que el esfuerzo merece la pena: un código más robusto, menos sorpresas desagradables y, sobre todo, la tranquilidad de saber que cada paso que damos está respaldado por una red de seguridad.