¿Qué es una "Unidad"?

Question

En el contexto de las pruebas unitarias, ¿qué es una "unidad"?

Answer 1

Normalmente lo defino como una sola ruta de ejecución de código a través de un único método. De la regla general se desprende que el número de pruebas unitarias requeridas para probar un método es igual o mayor que el número cyclomatic complexit del método y.

Answer 2

Definimos 'unidad' como una sola clase.

Como afirmas con acierto 'unit' es un término ambiguo y esto genera confusión cuando los desarrolladores simplemente usan la expresión sin agregar detalles. Donde trabajo nos tomamos el tiempo de definir a qué nos referimos cuando decimos 'prueba de unidad', 'prueba de aceptación', etc. Cuando alguien nuevo se une al equipo, aprenden las definiciones que tenemos.

Desde un punto de vista práctico, siempre habrá diferencias de opinión sobre qué es una 'unidad'. He descubierto que lo importante es simplemente que el término es usado sistemáticamente dentro del contexto de un proyecto.

Answer 3

Pueden ser cosas diferentes. Una clase, un módulo, un archivo ... Elija la granularidad de prueba que desee.

Answer 4

Aunque la definición puede variar, una "unidad" es una pieza de código independiente.

Por lo general, es una sola clase.

Sin embargo, existen pocas clases de forma aislada. Por lo tanto, a menudo tiene que burlarse de las clases que colaboran con su clase bajo prueba.

Por lo tanto, una "unidad" (también llamada "accesorio") es una prueba única, generalmente una clase más maquetas para los colaboradores.

Puede probar fácilmente un paquete de clases relacionadas utilizando la tecnología de prueba de la unidad. Hacemos esto todo el tiempo. Hay pocos o ningún simulacro en estos accesorios.

De hecho, puede probar programas completos de aplicaciones independientes como "unidades" individuales. Hacemos esto, también. Proporcionar un conjunto fijo de entradas y salidas para garantizar que la aplicación general haga las cosas correctamente.

Answer 5

Una unidad es cualquier elemento que se puede probar de forma aislada. Por lo tanto, uno casi siempre estará probando métodos en un entorno OO, y algunos comportamientos de clase donde hay un acoplamiento cercano entre los métodos de esa clase.

Answer 6

Yo diría que una unidad es una 'caja negra' que puede usarse dentro de una aplicación. Es algo que tiene una interfaz conocida y ofrece un resultado bien definido. Esto es algo que tiene que funcionar de acuerdo con una especificación de diseño y debe ser comprobable.

Habiendo dicho eso, a menudo uso pruebas unitarias al construir elementos dentro de tales 'cajas negras' solo como una ayuda al desarrollo.

Answer 7

Yo diría que una unidad en la unidad de prueba es una única pieza de responsabilidad para una clase.

Por supuesto, esta opinión proviene de la forma en que trabajamos:

En mi equipo que utilice las pruebas unitarias plazo para las pruebas donde probamos las responsabilidades de una sola clase. Usamos objetos simulados para cubrir todos los demás objetos de modo que las responsabilidades de las clases sean verdaderamente aisladas y no se vean afectadas si otros objetos tuvieran errores en ellas.

Utilizamos el término pruebas de integración para las pruebas en las que probamos cómo dos o más clases funcionan juntas, para que veamos que la funcionalidad real está ahí.

Finalmente, ayudamos a nuestros clientes a escribir pruebas de aceptación, que operan en la aplicación como un todo para ver qué sucede realmente cuando un "usuario" está trabajando con la aplicación.

Esto es lo que me hace pensar que es una buena descripción.

Answer 8

Si trabajo una 'unidad' es una función. Eso es porque no se nos permite usar ninguna otra cosa que no sea la descomposición funcional en nuestro diseño (sin OOP). Estoy de acuerdo al 100% con la respuesta de Will. Al menos esa es mi respuesta dentro del paradigma de mi trabajo en programación embebida para controles de motores y de vuelo y varios otros sistemas.

Answer 9

En mi experiencia, el debate sobre "qué es una unidad" es una pérdida de tiempo.

Lo que más importa es "¿qué tan rápido es la prueba?" Las pruebas rápidas se ejecutan a una velocidad de 100 +/segundo. Las pruebas lentas se ejecutan con la lentitud suficiente como para que no las ejecutes de forma refleja cada vez que te detengas a pensar.

Si sus pruebas son lentas, no las ejecutará con tanta frecuencia, lo que prolonga el tiempo entre la inyección de errores y la detección de errores.

Si sus pruebas son lentas, probablemente no obtenga los beneficios de diseño de las pruebas unitarias.

¿Quieres pruebas rápidas? Siga el rules of unit testing de Michael Feather.

Pero si tus pruebas son rápidas y te ayudan a escribir tu código, ¿a quién le importa qué etiqueta tienen?

Answer 10

Mi comprensión (o razón de ser) es que las unidades deben seguir una jerarquía de abstracción y alcance similar a la descomposición jerárquica de su código.

Un método es una pequeña y con frecuencia atómica operación (conceptualmente) a un bajo nivel de abstracción, por lo que debe ser probado

Una clase es un concepto de nivel medio que ofrece servicios y estados y, por tanto, debe hacerse la prueba .

Un módulo entero (especialmente si sus componentes están ocultos) es un concepto de alto nivel con una interfaz limitada, por lo que deben ser ensayados, etc.

Desde muchos errores surgen de las interacciones entre múltiples métodos y clases No veo cómo las pruebas unitarias solo los métodos individuales pueden lograr cobertura, hasta que ya tenga métodos que hagan uso de cada combinación importante, pero eso indicaría que no realizó las pruebas suficientes antes de escribir el código del cliente.

Answer 11

Eso no es importante. Por supuesto, es normal que solicite comenzar las pruebas unitarias, pero lo repito, no es importante.

La unidad es algo a lo largo de las líneas de:

• el método invocado por la prueba. En OOP este método debe invocarse en una instancia de una clase (excepto métodos estáticos)
• una función en los lenguajes de procedimiento.

Pero, la "unidad", la función o método, también puede invocar otra "unidad" de la aplicación, que está igualmente ejercido por la prueba. Entonces, la "unidad" puede abarcar varias funciones o incluso varias clases.

"La prueba es más importante que la unidad" (testivus). Una buena prueba será:

• automático - ejecución y de diagnóstico
• rápida - se encontrará con ellos muy a menudo
• Atómica - una prueba deberá probar una sola cosa
• aisladas - pruebas no deberán depender el uno del otro
• repetible - resultado será determinista