unit-testing - tipos - pruebas unitarias y de integración
Pruebas unitarias vs pruebas funcionales. (13)
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 .
Puedes 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 construcción que visita el sitio de construcción de una casa. Se enfoca 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 están escritas desde la perspectiva de los programadores . Se hacen para asegurar 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 esté funcionando como lo esperan los usuarios.
¿Cuál es la diferencia entre pruebas unitarias y pruebas funcionales? ¿Puede una prueba unitaria también probar una función?
"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: la length("hello") debe devolver 5 y la length("hi") debe devolver 2.
Vea también la toma de IBM en la línea entre pruebas de unidad y pruebas funcionales .
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, usamos la prueba funcional 4 para verificar si aparece un mensaje de error en 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.
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 pruebas de software - certificación ISTQB
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 this .
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
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.
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.
TLDR:
Para responder a la pregunta: la prueba unitaria es un subtipo de prueba funcional.
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 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 se juntan dos o más piezas (sub) módulos o (sub) sistemas y se ven 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 de rompecabezas se colocan juntas, se presenta
(3) Pruebas del sistema: pruebas de SW en su conjunto. Esto es más o menos "Pruebas de integración de todas las 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 se deben realizar durante todo el 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.
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 donde 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.
Las pruebas unitarias usualmente son hechas por 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.
Pruebas funcionales : Esta es una buena referencia. Explicación de pruebas funcionales
Prueba de unidad : - La prueba de unidad se usa 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 lo que respecta a las Pruebas, existen dos tipos principales de Pruebas como 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 la Prueba funcional : - El cliente ya está presente con sus requisitos y están debidamente documentados. La tarea de los evaluadores es verificar que la funcionalidad de la aplicación esté funcionando correctamente Al Sistema Propuesto o no. Para ese propósito, Tester debe probar la funcionalidad implementada con el sistema propuesto.
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, en realidad no es 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 el punto de vista del 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 devolverfalse.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 las escriben los desarrolladores junto con los usuarios (o quizás con las herramientas adecuadas y los usuarios adecuados, incluso para 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 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 principal.