unit-testing - tipos - pruebas unitarias y de integracion de software

¿Cuál es la diferencia entre integración y pruebas unitarias? (20)

¿Estas pruebas se han convertido esencialmente en pruebas de integración porque ahora prueban la integración de estas 2 clases? ¿O es solo una prueba de unidad que abarca 2 clases?

Creo que sí y sí. Su prueba de unidad que abarca 2 clases se convirtió en una prueba de integración.

Se podría evitar probando la clase Sentencia con implementación simulada: clase MockWord, lo cual es importante cuando esas partes del sistema son lo suficientemente grandes como para ser implementadas por diferentes desarrolladores. En ese caso, Word se prueba solo con la unidad, Sentencia se prueba con la unidad con la ayuda de MockWord, y luego se prueba la integración con Word.

Explicación de la diferencia real puede ser la siguiente: 1) La matriz de 1,000,000 de elementos se prueba en forma sencilla y funciona bien. 2) BubbleSort se prueba fácilmente en unidades en una matriz simulada de 10 elementos y también funciona bien 3) Las pruebas de integración muestran que algo no está tan bien.

Si estas partes son desarrolladas por una sola persona, el problema más probable se encontrará durante la prueba de unidad de BubbleSoft simplemente porque el desarrollador ya tiene una matriz real y no necesita una implementación simulada.

Conozco la llamada definición de libro de texto de pruebas unitarias y pruebas de integración. Tengo curiosidad por saber cuándo es el momento de escribir pruebas unitarias ... Las escribiré para cubrir el mayor número posible de clases.

Por ejemplo, si tengo una clase de Word , escribiré algunas pruebas unitarias para la clase de Word . Luego, comienzo a escribir mi clase de Sentence , y cuando necesite interactuar con la clase de Word , a menudo escribiré mis pruebas de unidad de tal manera que evalúen tanto la Sentence como la Word ... al menos en los lugares donde interactúan.

¿Estas pruebas se han convertido esencialmente en pruebas de integración porque ahora prueban la integración de estas 2 clases, o es solo una prueba unitaria que abarca 2 clases?

En general, debido a esta línea incierta, rara vez escribiré pruebas de integración ... o si utilizo el producto terminado para ver si todas las piezas funcionan correctamente las pruebas de integración reales, aunque sean manuales y rara vez se repitan más allá del alcance de cada característica individual?

¿Estoy entendiendo mal las pruebas de integración, o hay realmente muy poca diferencia entre la integración y las pruebas unitarias?

Editar

Gracias por todas las grandes respuestas a todos! Creo que, a partir de las variadas respuestas, queda claro que la línea entre la unidad y las pruebas de integración es definitivamente una línea borrosa, y tal vez sea un poco pedante tratar de averiguar cuáles son cuáles y cuál es el verdadero enfoque en el código (Gracias, @Rob Cooper ). Además, lo siento, pero no voy a aceptar ninguna respuesta porque demasiadas son demasiado buenas, y realmente parece bastante subjetivo.

Además, es importante recordar que tanto las pruebas unitarias como las pruebas de integración se pueden automatizar y escribir utilizando, por ejemplo, JUnit. En las pruebas de integración de JUnit, se puede usar la clase org.junit.Assume para probar la disponibilidad de elementos del entorno (por ejemplo, conexión de base de datos) u otras condiciones.

Creo que cuando empiezas a pensar en las pruebas de integración, estás hablando más de un cruce entre capas físicas en lugar de capas lógicas.

Por ejemplo, si sus pruebas se refieren a la generación de contenido, es una prueba unitaria: si su prueba se preocupa solo por escribir en el disco, sigue siendo una prueba unitaria, pero una vez que comprueba tanto la E / S Y el contenido del archivo, Entonces te tienes una prueba de integración. Cuando prueba la salida de una función dentro de un servicio, es una prueba de unidad, pero una vez que realiza una llamada de servicio y ve si el resultado de la función es el mismo, entonces es una prueba de integración.

Técnicamente no puedes hacer una prueba de unidad de una sola clase de todos modos. ¿Qué pasa si su clase se compone con varias otras clases? ¿Eso lo convierte automáticamente en una prueba de integración? No lo creo.

Creo que todavía llamaría a un par de clases interactivas una prueba de unidad siempre que las pruebas de unidad para class1 estén probando las características de class1, y las pruebas de unidad para class2 estén probando sus características, y también que no estén llegando a la base de datos.

Llamo a una prueba una prueba de integración cuando se ejecuta en la mayor parte de mi pila e incluso llega a la base de datos.

Realmente me gusta esta pregunta, porque la discusión de TDD a veces me parece demasiado purista, y es bueno para mí ver algunos ejemplos concretos.

Cuando escribo pruebas unitarias, limito el alcance del código que se está probando a la clase que estoy escribiendo actualmente con burlas de dependencias. Si estoy escribiendo una clase de oración, y la oración tiene una dependencia de Word, usaré una palabra simulada. Al burlarme de Word, me puedo centrar solo en su interfaz y probar los diversos comportamientos de mi clase de oración, ya que interactúa con la interfaz de Word. De esta manera solo estoy probando el comportamiento y la implementación de Sentencia y no al mismo tiempo probando la implementación de Word.

Una vez que he escrito las pruebas unitarias para garantizar que la oración se comporte correctamente cuando interactúa con Word en función de la interfaz de Word, escribo la prueba de integración para asegurarme de que mis suposiciones sobre las interacciones son correctas. Para esto, proporciono los objetos reales y escribo una prueba que ejerce una función que terminará usando Sentencia y Palabra.

En mi opinión, la respuesta es "¿Por qué importa?"

¿Es porque las pruebas unitarias son algo que haces y las pruebas de integración son algo que no haces? ¿O viceversa? Por supuesto que no, deberías intentar hacer ambas cosas.

¿Es porque las pruebas unitarias deben ser rápidas, aisladas, repetibles, autovalidantes y oportunas y las pruebas de integración no? Por supuesto que no, todas las pruebas deben ser estas.

¿Es porque usa simulacros en pruebas unitarias pero no los usa en pruebas de integración? Por supuesto no. Esto implicaría que si tengo una prueba de integración útil, no puedo agregar un simulacro por alguna parte, temo que tendría que cambiar el nombre de mi prueba a "prueba unitaria" o entregarla a otro programador para que trabaje.

¿Es porque las pruebas unitarias prueban una unidad y las pruebas de integración prueban varias unidades? Por supuesto no. ¿De qué importancia práctica es eso? La discusión teórica sobre el alcance de las pruebas se desglosa en la práctica de todos modos porque el término "unidad" depende completamente del contexto. En el nivel de clase, una unidad puede ser un método. En un nivel de ensamblaje, una unidad puede ser una clase, y en el nivel de servicio, una unidad puede ser un componente. E incluso las clases usan otras clases, entonces ¿cuál es la unidad?

No tiene importancia.

Las pruebas son importantes, FIRST es importante, dividir los pelos de las definiciones es una pérdida de tiempo que solo confunde a los recién llegados a las pruebas.

Hago lo mismo: les llamo a todas las pruebas de unidad, pero en algún momento tengo una "prueba de unidad" que cubre tanto que a menudo la renombro a "..IntegrationTest" - solo un cambio de nombre, nada más cambia.

Creo que hay una continuación de "pruebas atómicas" (probar una clase pequeña o un método) a pruebas unitarias (nivel de clase) y pruebas de integración, y luego pruebas funcionales (que normalmente cubren muchas más cosas desde arriba hacia abajo) - No parece haber un corte limpio.

Si su prueba configura datos, y tal vez carga una base de datos / archivo, etc., tal vez sea más una prueba de integración (las pruebas de integración encuentran menos simulacros y más clases reales, pero eso no significa que no pueda burlarse de algunos del sistema).

La prueba de unidad es la prueba de una unidad de trabajo o un bloque de código, si lo desea. Generalmente realizado por un solo desarrollador.

La prueba de integración se refiere a la prueba que se realiza, preferiblemente en un servidor de integración, cuando un desarrollador confirma su código en un repositorio de control de origen. Las pruebas de integración pueden ser realizadas por utilidades como Cruise Control.

Así que realiza la prueba de la unidad para validar que la unidad de trabajo que ha construido funciona y luego la prueba de integración valida que lo que haya agregado al repositorio no rompió otra cosa.

Llamo a las pruebas unitarias esas pruebas que la caja blanca prueba una clase. Cualquier dependencia que la clase requiera es reemplazada por una falsa (simulacros).

Las pruebas de integración son aquellas pruebas en las que se prueban múltiples clases y sus interacciones al mismo tiempo. Solo algunas dependencias en estos casos son falsas / simuladas.

No llamaría las pruebas de integración del Controlador a menos que una de sus dependencias sea una real (es decir, no falsificada) (por ejemplo, Autenticación IForms).

Separar los dos tipos de pruebas es útil para probar el sistema en diferentes niveles. Además, las pruebas de integración tienden a ser de larga duración, y se supone que las pruebas unitarias son rápidas. La distinción de la velocidad de ejecución significa que se ejecutan de manera diferente. En nuestros procesos de desarrollo, las pruebas unitarias se ejecutan al momento del check-in (lo cual es bueno porque son súper rápidos), y las pruebas de integración se ejecutan una o dos veces al día. Intento y ejecuto las pruebas de integración tan a menudo como sea posible, pero por lo general golpeando la base de datos / escribiendo en archivos / haciendo que rpc / ralentice.

Eso plantea otro punto importante, las pruebas unitarias deben evitar golpear IO (por ejemplo, disco, red, db). De lo contrario se ralentizan mucho. Se requiere un poco de esfuerzo para diseñar estas dependencias de E / S: no puedo admitir que he sido fiel a la regla de "las pruebas de unidad deben ser rápidas", pero si lo es, los beneficios de un sistema mucho más grande se harán evidentes muy rápidamente .

Los ejemplos anteriores funcionan muy bien y no necesito repetirlos. Así que me centraré en usar ejemplos para ayudarte a entender.

Pruebas de integración

Las pruebas de integración verifican si todo está funcionando en conjunto. Imagina una serie de engranajes trabajando juntos en un reloj. Una prueba de integración sería: ¿el reloj dice la hora correcta? ¿Sigue diciendo la hora correcta en 3 días?

Todo lo que te dice es si la pieza en general está funcionando. Si falla: no te dice exactamente dónde está fallando.

Pruebas unitarias

Estos son tipos de prueba realmente específicos. Te dicen si una cosa específica está funcionando o está fallando. La clave de este tipo de prueba es que prueba solo una cosa específica al tiempo que supone que todo lo demás funciona bien. Ese es el punto clave.

Ejemplo: Vamos a elaborar sobre este punto usando un ejemplo:

Tomemos un coche como ejemplo.
Prueba de integración para un automóvil: por ejemplo, el automóvil conduce a Echuca y regresa. Si lo hace, puede decir con seguridad que un automóvil está funcionando desde un punto de vista general. Es una prueba de integración. Si falla, no tiene idea de dónde está fallando realmente: ¿es el radiador, la transmisión, el motor o el carburador? No tienes idea. Podría ser cualquier cosa.
Prueba unitaria para un coche: que el motor esté funcionando. Esta prueba asume que todo lo demás en el automóvil funciona bien. De esa manera, si falla esta prueba de unidad en particular: puede estar muy seguro de que el problema está en el motor, por lo que puede aislarlo rápidamente y solucionarlo.

Las consecuencias de mezclar su integración y pruebas unitarias:

Supongamos que la prueba de integración de su automóvil falla. No conduce con éxito a Echuca. ¿Dónde está el problema?
Miras en tu prueba de motor. Pero en este caso particular, la prueba del motor utiliza dependencias externas: utiliza un sistema de combustible especial. Supongamos que la prueba de la unidad del motor también ha fallado. En otras palabras, tanto la prueba de integración como la prueba de la unidad del motor han fallado. ¿Dónde está entonces el problema? (Dése 10 segundos para obtener la respuesta). • ¿Falla el motor o fue el sistema de combustible lo que hizo que el motor fallara?

¿Ves el problema aquí? No sabes qué es exactamente lo que está fallando. Si usa 10 dependencias, entonces cada una de esas 10 podría haber causado el problema, y no sabrá por dónde empezar. Es por eso que las pruebas de unidad se burlan al asumir que todo lo demás funciona bien.

Espero que esto ayude.

Mis 10 bits: D

Siempre me dijeron que las pruebas unitarias son las pruebas de un componente individual , que deben ejercerse al máximo. Ahora, esto tiende a tener muchos niveles, ya que la mayoría de los componentes están hechos de partes más pequeñas. Para mí, una unidad es una parte funcional del sistema. Por lo tanto, tiene que proporcionar algo de valor (es decir, no es un método para analizar cadenas, sino quizás un HtmlSanitizer ).

Pruebas de integración es el siguiente paso, toma uno o más componentes y se asegura de que funcionen juntos como deberían. Luego, está por encima de las complejidades de preocuparse por cómo funcionan los componentes individualmente, pero cuando ingresa html en su HtmlEditControl , de alguna manera sabe mágicamente si es válido o no ...

Sin embargo, es una línea móvil real. Prefiero concentrarme más en lograr que el maldito código funcione por completo ^ _ ^

Para mí, la diferencia clave es que las pruebas de integración revelan si una característica está funcionando o está dañada, ya que enfatizan el código en un escenario cercano a la realidad. Invocan uno o más métodos o características de software y prueban si actúan como se espera.

Por el contrario, una prueba de prueba unitaria de un solo método se basa en la suposición (a menudo errónea) de que el resto del software funciona correctamente, porque se burla explícitamente de todas las dependencias.

Por lo tanto, cuando una prueba de unidad para un método que implementa alguna característica es verde, no significa que la característica esté funcionando.

Digamos que tienes un método como este:

public SomeResults DoSomething(someInput) { var someResult = [Do your job with someInput]; Log.TrackTheFactYouDidYourJob(); return someResults; }

DoSomething es muy importante para su cliente: es una característica, lo único que importa. Es por eso que usualmente escribes una especificación de pepino afirmándola: deseas verificar y comunicar si la función está funcionando o no.

Feature: To be able to do something In order to do something As someone I want the system to do this thing Scenario: A sample one Given this situation When I do something Then what I get is what I was expecting for

No hay duda: si la prueba pasa, puede afirmar que está entregando una característica de trabajo. Esto es lo que puedes llamar Valor Empresarial .

Si desea escribir una prueba de unidad para DoSomething , debe fingir (con algunos simulacros) que el resto de las clases y los métodos funcionan (es decir, que todas las dependencias que usa el método funcionan correctamente) y afirmar que su método funciona correctamente. .

En la práctica, haces algo como:

public SomeResults DoSomething(someInput) { var someResult = [Do your job with someInput]; FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log return someResults; }

Puede hacer esto con la inyección de dependencia, o algún método de fábrica o cualquier marco simulado o simplemente extendiendo la clase bajo prueba.

Supongamos que hay un error en Log.DoSomething() . Afortunadamente, la especificación Gherkin lo encontrará y sus pruebas de extremo a extremo fallarán.

La función no funcionará, porque el Log no funciona, no porque [Do your job with someInput] no está haciendo su trabajo. Y, por cierto, [Do your job with someInput] es la única responsabilidad de ese método.

Además, supongamos que Log se usa en otras 100 características, en otros 100 métodos de otras 100 clases.

Sí, 100 características fallarán. Pero, afortunadamente, 100 pruebas de punta a punta también están fallando y revelando el problema. Y sí , están diciendo la verdad .

Es una información muy útil: sé que tengo un producto roto. También es una información muy confusa: no me dice nada sobre dónde está el problema. Me comunica el síntoma, no la causa raíz.

Sin embargo, la DoSomething de la unidad de DoSomething es verde, porque utiliza un Log falso, creado para no romperse nunca. Y sí , está claramente mintiendo . Se está comunicando una función rota está funcionando. ¿Cómo puede ser útil?

(Si la prueba de la unidad de DoSomething() falla, asegúrese de que: [Do your job with someInput] tenga algunos errores).

Supongamos que este es un sistema con una clase rota:

Un solo error romperá varias características, y varias pruebas de integración fallarán.

Por otro lado, el mismo error romperá solo una prueba de unidad.

Ahora, compara los dos escenarios.

El mismo error romperá solo una prueba de unidad.

Todas sus características con el Log roto son rojas
Todas las pruebas unitarias son verdes, solo la prueba unitaria para el Log es roja

En realidad, las pruebas unitarias para todos los módulos que usan una característica rota son verdes porque, al usar simulacros, eliminaron las dependencias. En otras palabras, se ejecutan en un mundo ideal, completamente ficticio. Y esta es la única manera de aislar errores y buscarlos. La prueba unitaria significa burlarse. Si no te estás burlando, no estás haciendo pruebas de unidad.

La diferencia

Las pruebas de integración dicen lo que no funciona. Pero no sirven para adivinar dónde podría estar el problema.

Las pruebas unitarias son las únicas pruebas que le indican dónde está exactamente el error. Para dibujar esta información, deben ejecutar el método en un entorno simulado, donde todas las demás dependencias deben funcionar correctamente.

Por eso creo que su oración "O es solo una prueba de unidad que abarca dos clases" está de alguna manera desplazada. Una prueba de unidad nunca debe abarcar 2 clases.

Esta respuesta es básicamente un resumen de lo que escribí aquí: las pruebas de unidad mienten, por eso las amo .

Piense en la naturaleza de sus pruebas en los siguientes términos:

Reducción de riesgos : para eso están las pruebas. Solo una combinación de pruebas unitarias y pruebas de integración puede proporcionarle una reducción total del riesgo, ya que las pruebas unitarias no pueden probar inherentemente la interacción adecuada entre los módulos y las pruebas de integración pueden ejercer la funcionalidad de un módulo no trivial solo en pequeña medida.
Esfuerzo de escritura de la prueba : las pruebas de integración pueden ahorrar esfuerzo porque no necesita escribir talones / falsificaciones / simulacros. Pero las pruebas unitarias también pueden ahorrar esfuerzo al implementar (¡y mantener!) Que esos talones / falsificaciones / simulacros son más fáciles que configurar la configuración de la prueba sin ellos.
Retraso en la ejecución de la prueba : las pruebas de integración que involucran operaciones pesadas (como el acceso a sistemas externos como DBs o servidores remotos) tienden a ser lentas. Esto significa que las pruebas unitarias pueden ejecutarse con mucha más frecuencia, lo que reduce el esfuerzo de depuración si algo falla, porque tiene una mejor idea de lo que ha cambiado mientras tanto. Esto es particularmente importante si utiliza el desarrollo dirigido por pruebas (TDD).
Esfuerzo de depuración : si una prueba de integración falla, pero ninguna de las pruebas de unidad lo hace, esto puede ser muy inconveniente, porque hay mucho código involucrado que puede contener el problema. Esto no es un gran problema si anteriormente ha cambiado solo unas pocas líneas, pero como las pruebas de integración se ejecutan lentamente, quizás no las ejecutó en intervalos tan cortos ...

Recuerde que una prueba de integración todavía puede rechazar / simular / imitar algunas de sus dependencias. Esto proporciona una gran cantidad de terreno intermedio entre las pruebas unitarias y las pruebas del sistema (las pruebas de integración más completas, que prueban todo el sistema).

Por lo tanto, un enfoque pragmático sería: Confíe de manera flexible en las pruebas de integración tanto como pueda y utilice las pruebas unitarias cuando esto sea demasiado riesgoso o inconveniente. Esta forma de pensar puede ser más útil que la discriminación dogmática de las pruebas unitarias y las pruebas de integración.

Pruebas de integración: Se prueba la persistencia de la base de datos.
Pruebas unitarias: el acceso a la base de datos es simulado. Los métodos de código son probados.

Si eres un purista de TDD, escribe las pruebas antes de escribir el código de producción. Por supuesto, las pruebas no se compilarán, así que primero haga las compilaciones y luego las pase.

Puede hacer esto con pruebas unitarias, pero no puede con pruebas de integración o aceptación. Si lo intentaste con una prueba de integración, ¡nada se compilaría hasta que hayas terminado!

Un poco académico esta pregunta, ¿no? ;-) Mi punto de vista: Para mí, una prueba de integración es la prueba de toda la parte, no si dos de cada diez partes van juntas. Nuestra prueba de integración muestra si la compilación maestra (que contiene 40 proyectos) tendrá éxito. Para los proyectos tenemos toneladas de pruebas unitarias. Para mí, lo más importante con respecto a las pruebas unitarias es que una prueba unitaria no debe depender de otra prueba unitaria. Entonces, para mí, las dos pruebas que describiste anteriormente son pruebas unitarias, si son independientes. Para las pruebas de integración esto no tiene por qué ser importante.

Usando diseño de responsabilidad única, su blanco y negro. Más de 1 responsabilidad, es una prueba de integración.

Por la prueba de pato (miradas, curanderos, waddles, es un pato), es solo una prueba de unidad con más de 1 objeto nuevo en ella.

Cuando entras en mvc y lo pruebas, las pruebas del controlador siempre son integración, porque el controlador contiene tanto una unidad modelo como una unidad de visualización. Probando la lógica en ese modelo, llamaría a una prueba unitaria.

La prueba de unidad es un método de prueba que verifica que las unidades individuales del código fuente funcionan correctamente.

La prueba de integración es la fase de prueba de software en la que los módulos de software individuales se combinan y se prueban en grupo.

Wikipedia define una unidad como la parte comprobable más pequeña de una aplicación, que en Java / C # es un método. Pero en su ejemplo de clase de palabras y oraciones, probablemente solo escribiría las pruebas para la oración, ya que probablemente me parecería excesivo usar una clase de palabras mock para probar la clase de oraciones. Así que la oración sería mi unidad y la palabra es un detalle de implementación de esa unidad.

Las pruebas unitarias utilizan mocks.

De lo que está hablando son las pruebas de integración que realmente prueban toda la integración de su sistema. Pero cuando realiza pruebas de unidad, debe probar cada unidad por separado. Todo lo demás debería ser burlado. Entonces, en su caso de clase de Sentence , si usa la clase de Word , entonces su clase de Word debe ser burlada. De esta manera, solo Sentence la funcionalidad de tu clase de Sentence .

Prueba de unidad: La prueba realizada a una unidad o a una pieza de software más pequeña. Hecho para verificar si cumple con sus especificaciones funcionales o la estructura de diseño prevista.

Pruebas de integración: Prueba de los módulos relacionados juntos para su funcionalidad combinada.