it-swarm.dev

Pruebas unitarias vs pruebas funcionales.

¿Cuál es la diferencia entre las pruebas unitarias y las pruebas funcionales? ¿Puede una prueba unitaria también probar una función?

356
mousey

Prueba de unidad: prueba una unidad individual, como un método (función) en una clase, con todas las dependencias imitadas.

Prueba funcional: prueba de integración AKA, que prueba una porción de funcionalidad en un sistema. Esto probará muchos métodos y puede interactuar con dependencias como bases de datos o servicios web.

220
bpapa

Las pruebas unitarias le dicen a un desarrollador que el código está haciendo las cosas bien; las pruebas funcionales le dicen al desarrollador que el código está haciendo las cosas correctas .

Puede leer más en Pruebas unitarias versus Pruebas funcionales


A continuación se describe una analogía en la vida real bien explicada de las pruebas unitarias y funcionales.

Muchas veces el desarrollo de un sistema se compara con la construcción de una casa. Si bien esta analogía no es del todo correcta, podemos extenderla con el propósito de comprender la diferencia entre las pruebas funcionales y de unidad.

Las pruebas de unidad son análogas a las de un inspector de edificios que visita el sitio de construcción de una casa. Él está enfocado en los diversos sistemas internos de la casa, los cimientos, el armazón, la electricidad, la plomería, etc. Asegura (prueba) que las partes de la casa funcionarán de manera correcta y segura, es decir, que cumplan con el código de construcción.

Las pruebas funcionales en este escenario son análogas al propietario que visita este mismo sitio de construcción. Él asume que los sistemas internos se comportarán apropiadamente, que el inspector de construcción está realizando su tarea. El propietario se centra en cómo será vivir en esta casa. Le preocupa cómo se ve la casa, si las habitaciones son de un tamaño cómodo, si la casa satisface las necesidades de la familia, si las ventanas están en un buen lugar para tomar el sol de la mañana.

El propietario está realizando pruebas funcionales en la casa. Él tiene la perspectiva del usuario.

El inspector de construcción está realizando pruebas unitarias en la casa. Él tiene la perspectiva del constructor.


Como un resumen,

Las pruebas unitarias se escriben desde una perspectiva programadores. Se hacen para asegurar que un método particular (o un unidad) de una clase realice un conjunto de tareas específicas.

Las pruebas funcionales se escriben desde la perspectiva del usuario. Se aseguran de que el sistema sea en funcionamiento como lo esperan los usuarios.

469
Anthony Forloney
  • Una prueba de unidad prueba una unidad de comportamiento independiente. ¿Qué es una unidad de comportamiento? Es la pieza más pequeña del sistema que se puede probar de forma independiente. (Esta definición es en realidad circular, IOW no es realmente una definición en absoluto, pero parece funcionar bastante bien en la práctica, porque puedes entenderla de manera intuitiva).

  • Una prueba funcional prueba una pieza independiente de funcionalidad.


  • Una unidad de comportamiento es muy pequeña: aunque me desagrada absolutamente este estúpido mantra de "prueba de una unidad por método", desde la perspectiva tamaño es correcto. Una unidad de comportamiento es algo entre una parte de un método y quizás un par de métodos. A lo sumo un objeto, pero no más de uno.

  • Una pieza de funcionalidad generalmente comprende muchos métodos y cortes a través de varios objetos y, a menudo, a través de múltiples capas arquitectónicas.


  • Una prueba de unidad sería algo así como: cuando llamo a la función validate_country_code() y le paso el código de país 'ZZ', debería devolver false.

  • Una prueba funcional sería: cuando complete el formulario de envío con un código de país de ZZ, debería ser redirigido a una página de ayuda que me permita seleccionar mi código de país de un menú.


  • Las pruebas unitarias son escritas por desarrolladores, para desarrolladores, desde la perspectiva del desarrollador.

  • Las pruebas funcionales pueden ser enfrentadas por el usuario, en cuyo caso son escritas por los desarrolladores junto con los usuarios (o tal vez con las herramientas adecuadas y los usuarios adecuados, incluso por los propios usuarios), para los usuarios, desde la perspectiva del usuario. O pueden enfrentarse a los desarrolladores (por ejemplo, cuando describen una parte de la funcionalidad interna que al usuario no le importa), en cuyo caso están escritos por desarrolladores, para desarrolladores, pero aún desde la perspectiva del usuario.


  • En el primer caso, las pruebas funcionales también pueden servir como pruebas de aceptación y como una codificación ejecutable de los requisitos funcionales o una especificación funcional, en el último caso, también pueden servir como pruebas de integración.

  • Las pruebas unitarias cambian con frecuencia, las pruebas funcionales nunca deben cambiar dentro de una versión importante.


134
Jörg W Mittag

TLDR:

Para responder a la pregunta: Unit Testing es un subtipo de Functional Testing.


Hay dos grandes grupos: Funcional y No funcional Pruebas. La mejor ilustración (no exhaustiva) que encontré es esta (fuente: www.inflectra.com ):

 enter image description here

(1) Prueba de unidad: prueba de pequeños fragmentos de código (funciones/métodos). Puede considerarse como una prueba funcional (caja blanca).

Cuando se juntan las funciones, se crea un módulo = una pieza independiente, posiblemente con una Interfaz de Usuario que se puede probar (Prueba de Módulo). Una vez que tenga al menos dos módulos separados, luego los pegue y luego aparecerá:

(2) Pruebas de integración: cuando pones dos o más módulos (sub) módulos o (sub) sistemas juntos y ves si juegan bien juntos.

Luego integras el 3er módulo, luego el 4º y el 5º en el orden que tú o tu equipo consideren adecuado, y una vez que todas las piezas del rompecabezas se colocan juntas, se presenta

(3) Pruebas del sistema: prueba de SW como un todo. Esto es más o menos "Pruebas de integración de todas piezas juntas".

Si eso está bien, entonces viene

(4) Pruebas de aceptación: ¿construimos lo que el cliente solicitó en realidad? Por supuesto, las Pruebas de Aceptación deben realizarse a lo largo del ciclo de vida, no solo en la última etapa, donde se da cuenta de que el cliente quería un automóvil deportivo y usted construyó una camioneta.

 enter image description here

81
Andrejs

"Prueba funcional" no significa que esté probando una función (método) en su código. En general, significa que está probando la funcionalidad del sistema; cuando ejecuto foo file.txt en la línea de comandos, las líneas en file.txt se invierten, quizás. En contraste, una prueba de una sola unidad generalmente cubre un solo caso de un solo método: length("hello") debe devolver 5, y length("hi") debe devolver 2.

Vea también La toma de IBM en la línea entre la prueba de unidad y la prueba funcional .

11
Mark Rushakoff

De acuerdo con ISTQB, esos dos no son comparables. Las pruebas funcionales no son pruebas de integración.

La prueba de unidad es una de las pruebas de nivel y la prueba funcional es el tipo de prueba.

Básicamente:

La función de un sistema (o componente) es "lo que hace". Esto se describe normalmente en una especificación de requisitos, una especificación funcional o en casos de uso.

mientras

Las pruebas de componentes, también conocidas como pruebas de unidad, módulo y programa, buscan defectos y verifican el funcionamiento del software (por ejemplo, módulos, programas, objetos, clases, etc.) que se pueden probar por separado.

De acuerdo con ISTQB, la prueba de componente/unidad puede ser funcional o no funcional:

Las pruebas de componentes pueden incluir pruebas de funcionalidad y características no funcionales específicas, como comportamiento de recursos (por ejemplo, pérdidas de memoria), pruebas de rendimiento o robustez, así como pruebas estructurales (por ejemplo, cobertura de decisiones).

Citas de Fundamentos de las pruebas de software - Certificación ISTQB

7
Dominik

La distinción básica, sin embargo, es que las pruebas funcionales prueban la aplicación desde el exterior, desde el punto de vista del usuario. Las pruebas unitarias prueban la aplicación desde el interior, desde el punto de vista del programador. Las pruebas funcionales deben ayudarlo a crear una aplicación con la funcionalidad adecuada y garantizar que nunca la rompa accidentalmente. Las pruebas unitarias deberían ayudarlo a escribir un código limpio y libre de errores.

Tomado del libro "Python TDD" por Harry Percival

6
Humoyun

En Rails, la carpeta de la unidad debe contener pruebas para sus modelos, la carpeta funcional debe contener pruebas para sus controladores y la carpeta de integración debe contener pruebas que involucren cualquier número de controladores que interactúen. Los accesorios son una forma de organizar los datos de prueba; residen en la carpeta de accesorios. El archivo test_helper.rb contiene la configuración predeterminada para sus pruebas. Puedes visitar este .

6
Bhimasen Rautaray

AFAIK, la prueba unitaria NO es una prueba funcional. Déjame explicarte con un pequeño ejemplo. Desea probar si la funcionalidad de inicio de sesión de una aplicación web de correo electrónico funciona o no, como lo haría un usuario. Para eso, tus pruebas funcionales deberían ser así.

1- existing email, wrong password -> login page should show error "wrong password"!
2- non-existing email, any password -> login page should show error "no such email".
3- existing email, right password -> user should be taken to his inbox page.
4- no @symbol in email, right password -> login page should say "errors in form, please fix them!" 

¿Deberían nuestras pruebas funcionales verificar si podemos iniciar sesión con entradas no válidas? P.ej. El correo electrónico no tiene el símbolo @, el nombre de usuario tiene más de un punto (solo se permite un punto), ¿aparece .com antes de @ etc.? En general, no! Ese tipo de prueba entra en tus pruebas unitarias.

Puede verificar si las entradas no válidas se rechazan dentro de las pruebas unitarias como se muestra en las pruebas a continuación.

class LoginInputsValidator
  method validate_inputs_values(email, password)
    1-If email is not like [email protected], then throw error.
    2-If email contains abusive words, then throw error.
    3-If password is less than 10 chars, throw error.

Observe que la prueba funcional 4 realmente está haciendo lo que hace la prueba unitaria 1. A veces, las pruebas funcionales pueden repetir algunas (no todas) de las pruebas realizadas por pruebas unitarias, por diferentes motivos. En nuestro ejemplo, utilizamos la prueba funcional 4 para verificar si aparece un mensaje de error particular al ingresar una entrada no válida. No queremos probar si todas las entradas incorrectas son rechazadas o no. Ese es el trabajo de las pruebas unitarias.

3
MasterJoe2

La forma en que lo pienso es así: una prueba unitaria establece que el código hace lo que usted quería que hiciera el código (por ejemplo, quería agregar los parámetros a y b, de hecho, los agrega y no los resta), las pruebas funcionales comprueban que todo el código funciona en conjunto para obtener un resultado correcto, de modo que lo que pretendía que el código hiciera, de hecho, obtenga el resultado correcto en el sistema.

3
Yishai

EXAMEN DE LA UNIDAD

La prueba de unidad incluye la prueba de la unidad de código más pequeña, que generalmente son funciones o métodos. La prueba de la unidad la realiza principalmente el desarrollador de la unidad/método/función, ya que comprenden el núcleo de una función. El objetivo principal del desarrollador es cubrir el código por pruebas unitarias.

Tiene la limitación de que algunas funciones no se pueden probar a través de pruebas unitarias. Incluso después de la finalización con éxito de todas las pruebas de la unidad; No garantiza el correcto funcionamiento del producto. La misma función se puede usar en algunas partes del sistema, mientras que la prueba de la unidad se escribió solo para un uso.

PRUEBAS FUNCIONALES

Es un tipo de prueba de caja negra en la que se realizarán pruebas sobre los aspectos funcionales de un producto sin mirar el código. Las pruebas funcionales se realizan en su mayoría por un probador de software dedicado. Incluirá técnicas positivas, negativas y BVA utilizando datos no estandarizados para probar la funcionalidad especificada del producto. La cobertura de la prueba se realiza de una manera mejorada mediante pruebas funcionales que mediante pruebas unitarias. Utiliza la GUI de la aplicación para las pruebas, por lo que es más fácil determinar de qué es exactamente responsable una parte específica de la interfaz, en lugar de determinar de qué es responsable la función de un código.

2
Ashish Gupta

Prueba de unidad : - La prueba de unidad se utiliza particularmente para probar el componente del producto por componente especialmente mientras el producto está en desarrollo. El tipo de herramientas Junit y Nunit también lo ayudarán a probar el producto según la Unidad. ** En lugar de resolver los problemas después de la integración, siempre es cómodo resolverlos al principio del desarrollo.

Pruebas funcionales: - En cuanto a las Pruebas, existen dos tipos principales de Pruebas: 1. Prueba funcional 2. Prueba no funcional.

La prueba no funcional es una prueba en la que un probador probará que el producto realizará todos los atributos de calidad que el cliente no menciona, pero esos atributos de calidad deberían estar allí. Como: -Rendimiento, Usabilidad, Seguridad, Carga, Estrés, etc., pero en Prueba funcional : - El cliente ya está presente con sus requisitos y están debidamente documentados. La tarea de los evaluadores es verificar que la Aplicación La funcionalidad está funcionando de acuerdo con el Sistema Propuesto o no. Para ese propósito, Tester debe probar la funcionalidad implementada con el sistema propuesto.

1
mohit sarsar

Pruebas unitarias generalmente las realizan los desarrolladores. El objetivo de hacer lo mismo es asegurarse de que su código funcione correctamente. La regla general es cubrir todas las rutas en el código usando la prueba unitaria.

Prueba funcional : Esta es una buena referencia. Explicación de Pruebas Funcionales

0
automationuser