¿Pruebas unitarias o pruebas funcionales?[cerrado]

https://stackoverflow.com/questions/2230286

19-09-2019
|

Pregunta

Recientemente escuché sobre las pruebas funcionales en lugar de las pruebas unitarias.

Entiendo que Unit Testing prueba cada una de las posibilidades de un determinado fragmento de código desde su forma más atómica.Pero ¿qué pasa con las pruebas funcionales?

Esto me suena a probar solo si el código funciona, pero ¿es tan confiable como las pruebas unitarias?

Me han dicho que había dos escuelas de pensamiento al respecto.Algunos preferirían las pruebas unitarias, otros las pruebas funcionales.

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

¡Gracias!

Solución

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

Unidad de prueba = unidades de diseño (con desarrollo basado en pruebas, o TDD)
= Pruebas de integración hacen todas las piezas trabajan juntos
pruebas de aceptación del cliente = ¿cumple con los requerimientos del cliente
pruebas Manual = menudo cubre la interfaz de usuario; probadores dedicados pueden encontrar lo pierde de automatización
Las pruebas de carga = ¿qué tan bien el sistema realice con cantidades realistas de datos

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

Y hay otros; por más que la mayoría de la gente le importa saber, ver Pruebas de Software .

Uno de los puntos Personas perdidas es que la unidad de pruebas está probando piezas de código aisladamente . pruebas buena unidad no golpean la base de datos, por ejemplo. Esto tiene dos ventajas:. Hace que las pruebas se ejecutan rápido por lo que se encontrará más a menudo, y se le obliga a tener clases débilmente acoplados (mejor diseño)

Usted pidió recursos; Recomiendo el libro de Roy Osherove El arte de la Unidad de Pruebas con ejemplos en .NET . Mientras que ningún libro es perfecto, éste da excelentes consejos sobre cómo escribir buenas pruebas.

EDIT: Y para escribir las pruebas contra el software existente, no hay nada mejor libro de Michael plumas Trabajando Efectivamente con el código heredado .

Otros consejos

Prueba de la unidad frente a las pruebas funcionales no es una xor, sino más bien una and. Las pruebas unitarias se trata de unidades de prueba de forma aislada, mientras que las pruebas funcionales se acerca a prueba el conjunto en la integración (hacer todas las unidades trabaja juntos de manera adecuada?).

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

Prueba de la unidad a prueba sus unidades de código (métodos, etc.) para asegurarse de que hacen lo que se espera que lo hagan.

Las pruebas funcionales pone a prueba su diseño del sistema para asegurarse de que las piezas interactúan correctamente. Si se escribe un comando que se necesita y int y devuelve una cadena y poner a prueba su totalidad, usted puede estar seguro de que funciona. Pero si usted no tiene pruebas del sistema, es posible que nunca se notará que el resto del código piensa que puede aceptar un nulo pero no puede.

Los dos tipos de pruebas son importantes.

editar: Para añadir un punto de vista ligeramente diferente a lo gbjbaanb dijo:

Unidad de prueba = mi código funciona
Prueba de funcionamiento = mi diseño funciona
Prueba de integración = mi código está utilizando su material tercera parte correctamente (bases de datos, etc.)
funciona Factory Acceptance Test = mi sistema
Sitio de Pruebas de Aceptación = chupa su código, esto no es totalmente lo que pedí!?!

Unidad de prueba = más bajo, nivel granular.
Prueba de funcionamiento = mediocre, el nivel modular.
test Integración = mayor nivel de aplicación.
Prueba de Aceptación en Fábrica = ver que todo funcione
Pruebas de aceptación = verlo todo falla:)

Todo lo anterior son útiles pero no son mutuamente excluyentes. Que debería estar haciendo la mayor parte de ellos, pero la cantidad de tiempo que pasa en cada parte depende de los resultados que obtiene de ellos, eso es todo. Si el código es demasiado modular a ensayar fácilmente la unidad, a continuación, pasar sus esfuerzos en las pruebas funcionales. Si estás escribiendo una biblioteca de componentes pequeños, pasar su tiempo en la unidad de pruebas de ellos, y si usted está escribiendo sistemas de control de misiles militares que sin duda debe ser la aceptación lugar de la prueba ellos (como explosiones, incluso cuando no es divertido :))

Las pruebas funcionales, también llamado Las pruebas del sistema , tiene como objetivo probar el sistema completo, y la verificación los requisitos funcionales son satisfechos.

Prueba de la unidad tiene por objeto probar las "unidades", es decir, las funciones o métodos del sistema es construir a partir de aisladamente . A veces se le llama prueba de desarrollador. Prueba de la unidad puede ser difícil después de los hechos, por eso TDD escribe la prueba antes del código .

Esos son complementaria como las unidades pueden trabajar independientemente y no cuando se integran todos juntos, o pueden pasar las pruebas de unidad, y no cumplir con todos los requisitos del producto.

Unidad de Ensayos y pruebas funcionales tienen dos resultados diferentes.

Unidad de Pruebas verifica que una pequeña pieza de código funciona como se esperaba. Por lo general, se realiza por el desarrollador para asegurarse de que el código funciona correctamente. Por lo general, están automatizados por una prueba-marco también.

Functional Testing verifica que una característica funciona como se espera al pasar por una determinada vía a través del programa. Por lo general son ejecutados por una persona en el software de asegurar que el programa que funcionará forma en que se supone que es para el usuario. Es, como tal, es de nivel más alto, y por lo tanto a prueba varias unidades a la vez.

Creo que ambos son importantes. Si usted tiene recursos limitados, sin embargo, y tiene que escoger / elegir técnicas, y yo creo que depende de los productos que se crean, pero por lo que hago (productos de control de automóviles utilizados por los seres humanos a través de algunos botones) pruebas funcionales son los más importantes. Se comprueba, y asegura que, cuando el usuario recibe el producto, se hace lo que se supone que debe hacer. Esto no quiere decir que debemos optar por la unidad de pruebas, pero si push-viene-a-empujón, funcional es el más importante para asegurar la mejor experiencia de uso y conseguir el producto fuera de la puerta.

Si usted produce, por ejemplo, un motor de base de datos (o algún otro producto que no es necesariamente fácil de revestimiento), la unidad de pruebas puede ser lo que realmente debería hacer.

Una prueba unitaria prueba un fragmento de código y confirma al programador que otro fragmento de código está haciendo lo que se supone que debe hacer.En el desarrollo basado en pruebas, la prueba unitaria se escribe primero y se observa que falla, antes de que se escriba el código que hace que la prueba pase.Los programadores están interesados en las pruebas unitarias.Las pruebas unitarias son rápidas de ejecutar.

Una prueba de función prueba los requisitos de la caja negra y demuestra que una parte de la funcionalidad del usuario está implementada.Por ejemplo, si presiono el botón rojo grande, el timbre empieza a sonar.Es posible que la prueba funcional ni siquiera sea una prueba de código.Quizás exista un proceso mecánico que haga que el timbre suene al pulsar el botón.Los clientes están interesados en las pruebas funcionales porque confirman que se trata de un proceso de alto nivel si se trabaja de una manera que ellos entienden.Su ejecución suele ser lenta.

Hay un lugar para ambos en la mayoría del trabajo de desarrollo.

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

Prueba de funcionamiento está ahí para probar que la funcionalidad general del sistema es la esperada.

Son a diferentes niveles y ambos deben ser utilizados.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow