¿Prueba de unidad? ¿Examen de integración? ¿Test de regresión? ¿Examen de ingreso?

¿Hay alguien que pueda definir claramente estos niveles de prueba, ya que me resulta difícil diferenciar cuando hago pruebas de unidad o TDD? Por favor, si alguien puede explicar cómo y cuándo implementarlos.

Brevemente:

Prueba unitaria: prueba unitariamente cada fragmento de código individual. Piense en cada archivo o clase.

Prueba de integración : al juntar varias unidades que interactúan, debe realizar una prueba de integración para asegurarse de que la integración de estas unidades no haya introducido ningún error.

Prueba de regresión : después de la integración (y tal vez de la corrección), debe ejecutar nuevamente las pruebas unitarias. Se trata de una prueba de regresión para garantizar que los cambios posteriores no hayan roto ninguna unidad que ya se haya probado. La prueba unitaria que ya hizo ha producido las pruebas unitarias que se pueden ejecutar una y otra vez para las pruebas de regresión.

Pruebas de aceptación : cuando un usuario / cliente / empresa recibe la funcionalidad, ellos (o su departamento de pruebas) realizarán pruebas de aceptación para garantizar que la funcionalidad cumpla con sus requisitos.

Es posible que también desee investigar las pruebas de caja blanca y caja negra. También hay pruebas de rendimiento y carga, y pruebas de las "ilidades" a considerar.

Prueba unitaria: cuando falla, le dice qué parte de su código necesita ser reparada.

Prueba de integración: cuando falla, te dice que las piezas de tu aplicación no funcionan juntas como se esperaba.

Prueba de aceptación: cuando falla, te dice que la aplicación no está haciendo lo que el cliente espera que haga.

Prueba de regresión: cuando falla, te dice que la aplicación ya no se comporta como antes.

Aquí hay una explicación simple para cada una de las pruebas mencionadas y cuándo son aplicables:

Prueba de unidad Una prueba de unidad se realiza en una unidad autónoma (generalmente una clase o método) y debe realizarse siempre que se haya implementado una unidad o se haya completado la actualización de una unidad.

Esto significa que se ejecuta siempre que haya escrito una clase / método, solucionado un error, cambiado la funcionalidad ...

Prueba de integración La prueba de integración tiene como objetivo probar qué tan bien interactúan varias unidades entre sí. Este tipo de prueba debe realizarse siempre que se haya establecido una nueva forma de comunicación entre unidades o haya cambiado la naturaleza de su interacción.

Esto significa que se ejecuta cada vez que una unidad escrita recientemente se integra en el resto del sistema o siempre que una unidad que interactúa con otros sistemas se ha actualizado (y ha completado con éxito sus pruebas unitarias).

Prueba de regresión Las pruebas de regresión se realizan siempre que se ha modificado algo en el sistema, para comprobar que no se han introducido nuevos errores.

Esto significa que se ejecuta después de todos los parches, actualizaciones y correcciones de errores. Las pruebas de regresión pueden verse como un caso especial de prueba unitaria combinada y prueba de integración.

Prueba de aceptación Las pruebas de aceptación se realizan siempre que sea relevante para verificar que un subsistema (posiblemente el sistema completo) cumple con todas sus especificaciones.

Esto significa que se ejecuta principalmente antes de finalizar un nuevo entregable o anunciar la finalización de una tarea más grande. Vea esto como su verificación final para ver que realmente ha completado sus objetivos antes de correr hacia el cliente / jefe y anunciar la victoria.

Esta es al menos la forma en que aprendí, aunque estoy seguro de que hay otros puntos de vista opuestos. De cualquier manera, espero que eso ayude.

Lo intentaré:

1. Prueba unitaria: un desarrollador escribiría una para probar un componente o una clase individual.
2. Prueba de integración: una prueba más extensa que involucraría varios componentes o paquetes que necesitan colaborar
3. Prueba de regresión: hacer un solo cambio en una aplicación te obliga a volver a ejecutar TODAS las pruebas y comprobar TODAS las funciones.
4. Prueba de aceptación: los usuarios finales o el control de calidad lo hacen antes de firmar para aceptar la entrega de una aplicación. Dice "La aplicación cumplió con mis requisitos".

Prueba unitaria: ¿funciona correctamente mi método único? (NO dependencias, o dependencias burladas)

Prueba de integración: ¿Mis dos módulos desarrollados por separado funcionan correctamente cuando se combinan?

Prueba de regresión: ¿Rompí algo al cambiar / escribir un código nuevo? (La ejecución de pruebas unitarias / de integración con cada confirmación es técnicamente una prueba de regresión (automatizada)). Se utiliza con más frecuencia en el contexto del control de calidad: manual o automatizado.

Prueba de aceptación : prueba realizada por el cliente, que "acepta" el SW entregado

No puedo comentar (reputación baja: - |) así que ...

@Andrejs hace un buen comentario sobre las diferencias entre los entornos asociados con cada tipo de prueba.

Las pruebas unitarias se ejecutan normalmente en la máquina de los desarrolladores (y posiblemente durante la compilación de CI) con dependencias simuladas de otros recursos / sistemas.

Las pruebas de integración, por definición, deben tener (algún grado) de disponibilidad de dependencias; los demás recursos y sistemas se denominan para que el entorno sea más representativo. Los datos para las pruebas pueden ser burlados o un pequeño subconjunto ofuscado de datos de producción reales.

Las pruebas de aceptación / UAT deben representar la experiencia del mundo real para los equipos de QA y de negocios que aceptan el software. Por lo tanto, necesita una integración completa y volúmenes de datos realistas y conjuntos de datos enmascarados / ofuscados completos para ofrecer un rendimiento realista y una experiencia de usuario final.

Es probable que otras "ilidades" también necesiten que el entorno esté lo más cerca posible de la realidad para simular la experiencia de producción, por ejemplo, pruebas de rendimiento, seguridad, ...