¿Pruebas unitarias o pruebas funcionales?

Question

Hace poco escuché hablar de Pruebas funcionales sobre Pruebas unitarias.

Entiendo que Unit Testing evalúa cada una de las posibilidades de una determinada pieza de código desde su forma más atómica. Pero, ¿qué hay de las Pruebas Funcionales?

Esto me suena como que solo prueba si el código funciona, pero ¿es tan confiable como el Test de Unidad?

Me han dicho que había dos escuelas de pensamiento al respecto. Certains preferiría Pruebas Unitarias, otras Pruebas Funcionales.

¿Existen buenos recursos, enlaces, libros, referencias o alguno de ustedes que pueda explicar y aclarar mi camino en este tema?

Gracias!

Answer 1

La respuesta de Jason es correcta. Los diferentes tipos de pruebas tienen diferentes propósitos y se pueden superponer para obtener mejores resultados (buen diseño, especificaciones de reuniones, defectos reducidos).

• Unidad de prueba = unidades de diseño (con Test-Driven Development, o TDD)
• Las pruebas de integración = hacer todas las piezas trabajan juntos
pruebas de aceptación
• cliente = ¿cumple con los requisitos del cliente
• Las pruebas manuales = frecuencia cubre la interfaz de usuario; probadores dedicados pueden encontrar lo que la automatización pierde
• Las pruebas de carga = ¿qué tan bien el sistema realice con cantidades realistas de datos

Existe un cierto solapamiento entre estas categorías; las pruebas unitarias pueden especificar el comportamiento, por ejemplo.

Y hay otros; para más de lo que a la mayoría de la gente le importa saber, vea Software Testing.

Uno de los puntos que se omite es que la unidad de prueba está probando piezas de código en aislamiento. Las buenas pruebas unitarias no afectan a la base de datos, por ejemplo.Esto tiene dos ventajas: hace que las pruebas se ejecuten rápidamente, por lo que las ejecutará con más frecuencia y le obliga a escribir clases ligeramente acopladas (mejor diseño).

Ha solicitado recursos; Recomiendo el libro de Roy Osherove The Art of Unit Testing with Examples in .NET. Si bien ningún libro es perfecto, este ofrece muchos consejos excelentes para escribir buenas pruebas.

EDITAR: Y para escribir pruebas contra el software existente, nada es mejor que el libro de Michael Feathers Working Effectively with Legacy Code.

Answer 2

Pruebas unitarias versus pruebas funcionales no es un xor, sino un and. Las pruebas unitarias consisten en probar las unidades en forma aislada, mientras que las pruebas funcionales consisten en probar el todo en integración (¿todas las unidades funcionan juntas de manera adecuada?).

Ambos son componentes necesarios de buenas prácticas de ingeniería de software.

Answer 3

Hay un lugar para ambos en la mayoría de los trabajos de desarrollo.

La prueba de unidades está ahí para probar pequeñas unidades de código, para asegurarse de que funcionen como se esperaba.

Las pruebas funcionales comprueban que la funcionalidad general del sistema es la esperada.

Se encuentran en niveles diferentes y se deben usar ambos.

Answer 4

Las pruebas unitarias y las pruebas funcionales tienen dos resultados diferentes.

La Prueba de la unidad comprueba que un pequeño código funciona como se esperaba. Por lo general, el desarrollador lo hace para garantizar que el código funcione correctamente. Por lo general, también están automatizados por un marco de prueba.

La Prueba funcional verifica que una característica funciona como se esperaba al pasar por una determinada ruta a través del programa. Por lo general, son ejecutados por una persona en el software que garantiza que el programa funcionará de la manera que se supone que debe ser para el usuario. Es, como tal, un nivel más alto, y por lo tanto prueba varias unidades a la vez.

Creo que ambos son importantes. Sin embargo, si tiene recursos limitados y tiene que elegir/elegir técnicas, y creo que depende de los productos que crea, pero para lo que hago (productos de control automotriz usados ​​por humanos a través de algunos botones) las pruebas funcionales son las más importantes. Comprueba y asegura que cuando el usuario obtiene el producto, hace lo que se supone que debe hacer. Esto no significa que debemos optar por no participar en las pruebas unitarias, pero si el empuje viene a empujar, el más funcional es el más importante para garantizar una gran experiencia de usuario y sacar el producto a la calle.

Si produce, por ejemplo, un motor de base de datos (u otro producto que no necesariamente esté orientado al usuario), la prueba de unidad puede ser lo que realmente debería hacer.

Answer 5

• Prueba de unidad = nivel más bajo, granular.
• Prueba funcional = media, nivel modular.
• Prueba de integración = nivel de aplicación más alto.
• Factory Acceptance Test = ver que todo funcione
• Sitio de pruebas de aceptación = verlo todo al fracaso :)

Todo lo anterior son útiles pero no son mutuamente excluyentes. Deberías hacer la mayoría de ellas, pero la cantidad de tiempo que pasas en cada parte depende de los resultados que obtienes de ellas, eso es todo. Si su código es demasiado modular para ser probado fácilmente en unidades, dedique sus esfuerzos a las pruebas funcionales. Si está escribiendo una biblioteca de componentes pequeños, pase su tiempo en la unidad probándolos, y si está escribiendo sistemas de control para misiles militares, definitivamente debe ser una prueba de aceptación del sitio (como explosiones, incluso cuando falla es divertido :))

Answer 6

La prueba de unidades prueba sus unidades de código (métodos, etc.) para asegurarse de que hacen lo que usted espera.

Las pruebas funcionales prueban el diseño de su sistema para asegurarse de que las piezas interactúen correctamente. Si escribe un comando que toma e int, y devuelve una cadena y la prueba por completo, puede estar seguro de que funciona. Pero si no tiene pruebas del sistema, puede que nunca note que el resto del código cree que puede aceptar un valor nulo pero no puede.

Ambos tipos de pruebas son importantes.

de edición: Para añadir un punto de vista ligeramente diferente a lo gbjbaanb dijo: Prueba

• Unidad = mi código funciona
• Prueba de funcionamiento = mi diseño funciona
• Prueba de integración = mi código está usando su tercera cosas de fiesta correctamente (bases de datos, etc.)
• Prueba de aceptación de fábrica = mi sistema funciona
• Prueba de aceptación del sitio = su código apesta, esto no es lo que pedí!?!

Answer 7

La prueba funcional, también llamada System testing, tiene como objetivo probar el sistema completo y verificar que se cumplan los requisitos funcionales.

Unit testing tiene como objetivo probar las "unidades", es decir, las funciones o métodos del sistema se construye desde en aislamiento. A veces se llama prueba de desarrollador. Las pruebas unitarias pueden ser difíciles después del hecho, es por eso que TDD escribe la prueba antes del código.

Esos son complementarios ya que las unidades pueden funcionar independientemente y no cuando se integran todas juntas, o pueden pasar las pruebas de la unidad, y no cumplen todos los requisitos del producto.

Answer 8

Una prueba de unidad prueba una pieza de código y confirma para un programador que otra parte del código está haciendo lo que se supone que debe. En Desarrollo controlado por prueba, la prueba unitaria se escribe primero y se observa que falla, antes de que se escriba el código, lo que hace que pase la prueba. Los programadores están interesados ​​en pruebas unitarias. La prueba unitaria es rápida de ejecutar.

Una prueba de función prueba los requisitos de la caja negra y demuestra que hay una parte de la funcionalidad del usuario instalada. Por ejemplo, si presiono el botón rojo grande, la campana comienza a sonar. La prueba funcional puede que ni siquiera sea un código de prueba. Tal vez haya un proceso mecánico que haga sonar la campana al presionar el botón. Los clientes están interesados ​​en pruebas funcionales, ya que confirman que se trata de un proceso de alto nivel si se trabaja de una manera que ellos entiendan. A menudo son lentos para ejecutar.