Pruebas unitarias vs Pruebas funcionales

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

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

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.

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

Puede leer más en Pruebas unitarias versus Pruebas funcionales

Una analogía bien explicada de la vida real de las pruebas unitarias y las pruebas funcionales se puede describir de la siguiente manera:

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 fin de comprender la diferencia entre las pruebas unitarias y funcionales.

Las pruebas unitarias son análogas a las de un inspector de edificios que visita el sitio de construcción de una casa. Está enfocado en los diversos sistemas internos de la casa, los cimientos, la estructura, 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 a que el propietario visite este mismo sitio de construcción. Asume que los sistemas internos se comportarán adecuadamente, que el inspector de edificios 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 se adapta a 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. Tiene la perspectiva del usuario.

El inspector de edificios está realizando pruebas unitarias en la casa. Tiene la perspectiva del constructor.

Como un resumen,

Las pruebas unitarias se escriben desde la perspectiva de los programadores . Se hacen para garantizar que un método particular (o una 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 funcione como lo esperan los usuarios.

• Una prueba unitaria 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 realmente no es una definición en absoluto , pero parece funcionar bastante bien en la práctica, porque puedes entenderla intuitivamente).

• Una prueba funcional prueba una pieza independiente de funcionalidad.

• Una unidad de comportamiento es muy pequeña: si bien no me gusta en absoluto este estúpido mantra de "prueba de una unidad por método", desde una perspectiva de 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 en varios objetos y, a menudo, a través de múltiples capas arquitectónicas.

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

• Una prueba funcional sería: cuando complete el formulario de envío con un código de país ZZ, debería ser redirigido a una página de ayuda que me permita elegir el 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 estar orientadas al usuario, en cuyo caso las redactan los desarrolladores junto con los usuarios (o tal vez con las herramientas adecuadas y los usuarios correctos incluso por los propios usuarios), para los usuarios, desde la perspectiva del usuario. O pueden estar orientados al desarrollador (por ejemplo, cuando describen alguna pieza interna de funcionalidad 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 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 deberían cambiar dentro de una versión principal.

TLDR:

Para responder a la pregunta: Las pruebas unitarias son un subtipo de pruebas funcionales.

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

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

Cuando las funciones se unen, 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 tiene al menos dos módulos separados, los pega y luego viene:

(2) Pruebas de integración: cuando pone dos o más piezas de (sub) módulos o (sub) sistemas juntos y ve si funcionan bien juntos.

Luego integra el 3er módulo, luego el 4to y 5to en el orden que usted o su equipo lo consideren apropiado, y una vez que todas las piezas del rompecabezas están juntas, viene

(3) Prueba del sistema: prueba de SW en su conjunto. Esto es más o menos "Prueba de integración de todas las piezas juntas".

Si eso está bien, entonces viene

(4) Prueba de aceptación: ¿construimos lo que el cliente solicitó realmente? Por supuesto, las pruebas de aceptación deben realizarse durante todo el ciclo de vida , no solo en la última etapa, donde se da cuenta de que el cliente quería un auto deportivo y usted construyó una camioneta.

"Prueba funcional" no significa que esté probando una función (método) en su código. Significa, en general, que está probando la funcionalidad del sistema: cuando ejecuto foo file.txten la línea de comando, las líneas file.txtse invierten, tal vez. Por el contrario, 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 las pruebas unitarias y las pruebas funcionales .

Sin embargo, la distinción básica 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 deberían 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 código que esté limpio y libre de errores.

Tomado del libro "Python TDD" de Harry Percival

Según ISTQB, esos dos no son comparables. Las pruebas funcionales no son pruebas de integración.

La prueba de unidad es uno de los niveles de prueba 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 típicamente en una especificación de requisitos, una especificación funcional o en casos de uso.

mientras

La prueba de componentes, también conocida como prueba de unidad, módulo y programa, busca defectos y verifica el funcionamiento del software (por ejemplo, módulos, programas, objetos, clases, etc.) que se pueden probar por separado.

Según 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 el comportamiento de los recursos (por ejemplo, pérdidas de memoria), el rendimiento o las pruebas de robustez, así como las pruebas estructurales (por ejemplo, cobertura de decisiones).

Citas de Fundamentos de pruebas de software - certificación ISTQB

En Rails, la carpeta de la unidad está destinada a realizar pruebas para sus modelos, la carpeta funcional está destinada a realizar pruebas para sus controladores, y la carpeta de integración está destinada a realizar pruebas que involucran a cualquier número de controladores que interactúan. 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 esto .

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

AFAIK, las pruebas unitarias NO son pruebas funcionales. 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, tal como lo haría un usuario. Para eso, sus 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), .com aparece antes de @ etc.? En general, no! Ese tipo de prueba entra en las pruebas de su unidad.

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 en realidad está haciendo lo que está haciendo la prueba unitaria 1. A veces, las pruebas funcionales pueden repetir algunas (no todas) de las pruebas realizadas por pruebas unitarias, por diferentes razones. 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.

EXAMEN DE LA UNIDAD

Las pruebas unitarias incluyen pruebas de la unidad de código más pequeña, que generalmente son funciones o métodos. La prueba unitaria es realizada principalmente por el desarrollador de la unidad / método / función, porque entienden 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 pueden probarse mediante pruebas unitarias. Incluso después de completar con éxito todas las pruebas unitarias; 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 Black Box donde se realizarán pruebas sobre los aspectos funcionales de un producto sin mirar el código. La prueba funcional es realizada principalmente por un probador de software dedicado. Incluirá técnicas positivas, negativas y BVA que utilizan datos no estandarizados para probar la funcionalidad especificada del producto. La cobertura de la prueba se realiza de 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 un código de la función.

muy simplemente podemos decir:

• caja negra: prueba de interfaz de usuario como prueba funcional
• caja blanca: prueba de código como prueba unitaria

Lea más aquí .

Prueba unitaria : - La prueba unitaria se usa particularmente para probar el componente del producto por componente, especialmente mientras el producto está en desarrollo. Las herramientas de tipo 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 resolverlo temprano en el 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 que deben estar allí. Como: -Rendimiento, usabilidad, seguridad, carga, estrés, etc., pero en la prueba funcional : - El cliente ya está presente con sus requisitos y están debidamente documentados, la tarea de los verificadores es verificar si la funcionalidad de la aplicación está funcionando de acuerdo con al sistema propuesto o no. Para ese propósito, Tester debe probar la funcionalidad implementada con el sistema propuesto.

Las 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 código usando pruebas unitarias.

Pruebas funcionales : esta es una buena referencia. Explicación de pruebas funcionales