A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Sin pruebas no hay confianza

6/21
Recursos

Antes de que entremos a Continuos Integration debemos entrar a la parte fundamental de CI y es hacer pruebas. Sin pruebas no hay confianza.

Nuestro CI necesita pruebas que debe correr de forma automatizada como test unitarios, test de integraci贸n y test de aceptaci贸n, m铆nimo es necesario tener las dos primeras.

  • Unit tests usan mocks
  • Integration tests usan dependencias reales con fixtures
  • Acceptance tests usan un ambiente con todos los servicios, como si fuera producci贸n.

Aportes 7

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

Las pruebas de software (en ingl茅s software testing) son las investigaciones emp铆ricas y t茅cnicas cuyo objetivo es proporcionar informaci贸n objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. // Wikipedia //

Unit test: Prueba unitaria
Integration test: Prueba de integraci贸n
Aceptance test: Prueba de aceptaci贸n
System test: Prueba de Sistema
Component test: Prueba de Componente

Sin pruebas no hay confianza, y este es el fundamento de Continuous Integration.

Correr prueba manualmente es una p茅rdida de tiempo. Est谩 bien que el desarrollador realice pruebas en su m谩quina local, pero esa no debe ser la confianza que se debe tener para saber que se hicieron pruebas. Se debe tener un sitio centralizado donde se ejecuten las pruebas, y debe haber pruebas de todo.
Con 鈥渟itio centralizado鈥 es cuando entra en juego el servidor de CI, y este servidor necesita pruebas que correr, o no sirve de nada.

Se debe tener en un entorno de trabajo pruebas unitarias, pruebas de integraci贸n y pruebas de aceptaci贸n. Las dos primeras pueden ejecutarse en un entorno local.
Este ser铆a el escenario perfecto para unas buenas pruebas, pero en caso de no poderse, se debe contar como m铆nimo con las dos primeras pruebas.

En las pruebas unitarias, pueden utilizarse mocks para simular u omitir el comportamiento de ciertos elementos que no puedan ser probados aqu铆 (conexiones a bases de datos, respuestas de servicios de proveedores en la nube, etc).

Las pruebas de integraci贸n utilizan dependencias reales con fixtures (como dumps o seeders para las bases de datos, o incluso se puede crear informaci贸n de forma manual) que no necesariamente deben ser reales, pero deben simular serlo.

Las pruebas de aceptaci贸n son desplegadas en un ambiente de staging, que debe ser lo m谩s parecido posible a producci贸n a nivel de estructura de proyecto y de infraestructura en la nube.

Al implementar estas pruebas, tenemos mucha confianza y garant铆a de que el c贸digo se est谩 comportando bien; si las pruebas no pasan, el c贸digo no debe ser desplegado a producci贸n, sea cualquiera de las pruebas, porque las pruebas nos dan confianza.

Para poder desplegar c贸digo de manera segura a producci贸n, debemos tener confianza.

Unit test: utilizan mocks
Integration test: realizan dependencias reales
Acceptance tests: Usan un ambiente con todos los servicios como si fuera producci贸n.

Como se crea un ambiente de staging?

Los test nos dan confianza y para correr los test en producci贸n hay que tener confianza!

Es muy ciero que debemos de contar con pruebas porque tal como lo dicen sin pruebas no puede haber confianza

TESTTTT toca pq toca. Minimiza los inconvenientes en produccion.