Casos de Prueba
Closed this issue · 2 comments
Hola!
Tengo una pregunta teórica sobre los casos de pruebas.
Está bien hacer dos casos de prueba sobre el mismo requerimiento/condición pero con inputs distintos (y que retornen distinto)? O eso es considerado un caso de prueba redundante?
Como por ejemplo, hacer dos casos de prueba:
-
Caso 1: Prueba que se cumpla la condición X, con input valido (ó Prueba que se cumpla la condición X) -> retorna True
-
Caso 2: Prueba que se cumpla la condición X, con input invalido (ó Prueba que no se cumpla la condición X) -> retorna False
Gracias!
Hola,
No sé si entiendo bien tu pregunta (en específico porque me parece que tu ejemplo no representa lo mismo que preguntabas), pero trataré de aclarar a lo que se refieren los casos de prueba redundantes.
Dado un criterio de cobertura, este define el conjunto de requisitos de prueba que los casos de prueba deben abarcar para cumplir con 100% de cobertura bajo ese criterio. Al momento de diseñar los casos de pruebas, se debe tratar que con el mínimo número de pruebas posibles se abarque la mayor cantidad de requisitos de prueba, para así cumplir de manera eficiente con el criterio de cobertura.
Si al agregar una prueba a un conjunto de pruebas esta no abarca ningún requisito de prueba adicional a los que el resto de las pruebas cumplen, entonces esa prueba sería redundante para ese conjunto de pruebas y requisitos de pruebas. Sin embargo, puede ser que pruebas que son redundantes bajo un criterio de cobertura sean necesarias para cumplir con otro criterio de cobertura más exigente.
En tu ejemplo los casos de prueba retornan resultados diametralmente opuestos como lo son True y False, por lo que esas pruebas no podrían considerarse redundantes. En cambio, si la función que pruebas suma 2 números, y tienes un caso 1 + 1 = 2 y otro caso 2 + 2 = 4, estos si se podrían considerar redundantes para ciertos criterios de cobertura porque a pesar de que el output es distinto, las pruebas validan la misma lógica (o flujo) del programa. De todas maneras, si tu criterio de cobertura definiera los requisitos de prueba como que "el primer número sea igual al segundo", "el primer número sea mayor al segundo", "el primer número sea menor al segundo", tanto para los casos en que ambos son positivos y negativos, entonces tus pruebas no serían redundantes porque cada una abarca un requisito de prueba que el resto no cumple. Sin embargo, puede ser que estos requisitos de prueba no sean útiles para encontrar bugs, por lo que valdría más la pena evaluar el código bajo otro criterio de cobertura.
Por otro lado, si tu pregunta está relacionada al ejercicio sobre diseño de pruebas de la actividad 1, el objetivo de este no es que lo analicen con 100% de cobertura, sino que puedan detectar los casos de prueba más relevantes para desarrollar la funcionalidad.
Saludos,
Perfecto! Me queda mucho más claro
Gracias!