Clase 26 de 31 • Curso de Introducción al Pensamiento Computacional con Python
Contenido del curso
Ingrid Natalia Rodriguez Ovalle
René Sanchez
Cristian Antonio García González
David Gallego
Fernando Jesús Núñez Valdez
María Cristina Chuchón Pérez
Karl Behrens Gil
Cristian Camilo Berrio Montoya
Karl Behrens Gil
Manuel Alejandro Hermoso
Francisco Javier Mendoza Flores
Manuel Alejandro Hermoso
Víctor Raúl Grajeda Aranda
Ignacio Crespo
Dana Curiel
Ángel David Roque Ayala
Pedro Emmanuel Notario Hernández
Fabrizio Fasanando Sotelo
Miguel Angel Reyes Moreno
Mauricio Gonzalez Falcon
Luis Rogelio Ponce Perez
José Raúl Gómez Hinojosa
Eden Gomez Gress
Wilmer Diaz
Wilmer Diaz
Pablo Reyes Abarca
Joseph Michael Ciriaco Bermudez
Andrés Felipe Díaz Rodríguez
Felipe Cortés
Rubén Padilla
Daniel Arenas
Felipe Cortés
Julián Gamboa
Orlando Ramirez
Gonzalo Ferrando
Daniel Guarín García
Rubén Cuello
Miguel Angel Velazquez Romero
Miguel Angel Velazquez Romero
Luis Mendoza
Kevin Morales
Daniel Eduardo Montero Ramírez
Iván Ricardo Bohórquez Basto
Anthony González (@ThonnyGeek)
Paul Bravo
Juan David Cepeda López
Marco Melendez
Rubén Padilla
Angel Estrada
El testing tambien es un campo interesante, Aqui la lista de los ** 7 principios de Testing ** de acuerdo al libro de ISTQB.
1 Las pruebas muestran la presencia de defectos Significa que las pruebas pueden demostrar que EXISTEN problemas, pero no que los problemas NO EXISTEN. El objetivo principal de llevar a cabo una prueba es para detectar defectos. Trabajando bajo la premisa de que cada producto contiene defectos de algún tipo, una prueba que revela los errores es generalmente mejor que una que no lo hace. Todas las pruebas por lo tanto, deben ser diseñados para revelar tantos errores como sea posible
2 Las pruebas exhaustivas son imposibles Las pruebas exhaustivas tratan de cubrir todas las combinaciones posibles de datos en el software, a fin de garantizar que ninguna situación puede surgir, una vez probado el software se ha liberado. Excepto en aplicaciones muy simples, el número de combinaciones posibles de datos es demasiado alta, es más eficaz y eficiente que los ingenieros de pruebas se centren en las funcionalidades de acuerdo a riesgos y prioridades.
3 Pruebas tempranas. Un producto (incluyendo los documentos, tales como la especificación del producto) se puede probar tan pronto como se ha creado. ISTQB recomienda probar un producto tan pronto como sea posible, corregir los errores más rápidamente posible. Los estudios han demostrado que los errores identificados al final del proceso de desarrollo por lo general cuestan más para resolver. Por ejemplo: un error encontrado en las especificaciones puede ser bastante sencillo de solucionar. Sin embargo, si ese error se transfiere a la codificación de software, una vez descubierto el error puede ser muy costoso y consume tiempo.
4 Agrupamiento de Defectos Los estudios sugieren que los problemas en un elemento de software tienden a agruparse en torno a un conjunto limitado de módulos o áreas. Una vez que estas áreas han sido identificadas, los administradores eficientes de prueba son capaces de enfocar las pruebas en las zonas sensibles, mientras que siguen buscando a los errores en los módulos de software restantes. Me recuerda al 80/20.
5 La paradoja del “Pesticida” Al igual que el sobre uso de un pesticida, un conjunto de pruebas que se utilizan repetidamente en el disminuirá en su eficacia. Usando una variedad de pruebas y técnicas expondrá una serie de defectos a través de las diferentes áreas del producto.
6 La prueba es dependiente del contexto Las mismas pruebas no se deben aplicar en todos los ámbitos. Distintos productos de software tienen diferentes requisitos, funciones y propósitos. Una prueba diseñada para realizarse en un sitio web, por ejemplo, puede ser menos eficaz cuando se aplica a una aplicación de intranet. Una prueba diseñada para una forma de pago con tarjeta de crédito puede ser innecesariamente rigurosa si se realiza en un foro de discusión. En general, cuanto mayor es la probabilidad y el impacto de los daños causados por el software fallado, mayor es la inversión en la realización de pruebas de software.
7 La falacia de ausencia de errores Declarar que una prueba no ha descubierto ningún error no es lo mismo que declarar que el software es “libre de errores”. Con el fin de garantizar que los procedimientos adecuados de software de prueba se lleva a cabo en todas las situaciones, los evaluadores deben asumir que todo el software contiene algunos (aunque disimulada) errores.
Muy buen aporte ❤
Wooowww que genial aporte, realmente increíble muchas gracias por compartirlo con nosotros compañero.
if __name__ == '__main__': unittest.main(verbosity=2)
Se le puede agregar el parámetro verbosity=2 al método unittest.main para que el resultado en la consola sea mas detallado.
Muchas gracias!!
buen dato, lo probaré.
Les dejo el links a mis apuntes https://github.com/karlbehrensg/introduccion-pensamiento-computacional
Pruebas de caja de cristal
Se basan en el flujo del programa, por lo que se asume que conocemos el funcionamiento del programa, por lo que podemos probar todos los caminos posibles de una función. Esto significa que vamos a probar las ramificaciones, bucles for y while, recursiónes, etc.
Este tipo de pruebas son muy buenas cuando debemos realizar:
Cuánto tiempo te toma para hacer esas notas ? En cuanto terminas un curso y como te organizas para hacer todo eso? Te envidio porque muchas veces no se ni de que tomar notas me gustaría que me dieras algunos concejos porfavor
Hola kmiiloberrio02, estas notas me tomaron 5 días hacerlo mientras avanzaba en el curso.
Antes simplemente escuchaba los cursos y aplicaba los ejemplos, pero en mi caso solo quedaba esos conocimientos en la memoria de corto plazo. Ahora voy pausando los videos y voy escribiendo las cosas, así logro retener lo aprendido en la memoria a largo plazo.
Te recomiendo el curso de como aprender en línea de Anahí https://platzi.com/clases/aprender/ ahí te explican a detalle.
No hay que entender el aspecto técnico al 100%.
. Solo tienes que quedarte con que estas herramientas se utilizan para prevenir - futuros errores. . Como cuando un arquitecto dibuja el plano de una casa que se va a construir y - determina que las ventanas deben ser rectangulares.
Si el albañil instala ventanas circulares la forma más sencilla de detectar un error es volver al plano original. .
Las ventanas circulares cumplen la misma función que unas rectangulares pero- están fuera del contexto que se le prometió al futuro dueño de la casa. .
Con Unittest
podemos establecer algo similar a un plano como la base de desarrollo de forma que nuestro código no se salga de contexto.
Me gustó tu analogía.
gracias @kascajo :)
La diferencia entre las pruebas de Caja Negra y ++Caja de Cristal++ es que en las pruebas de caja negra se escriben primero los test para ayudarnos a implementar nuevo código. En las pruebas de ++caja de cristal++ se asume que se tiene código escrito y las pruebas se escriben para verificar todas las ramificaciones del programa y probar todos los diferentes caminos posibles.
Excelente aporte compañero! Soy nuevo en esto y no lograba entender sus diferencias y por qué utilizar una y no la otra según lo que necesites.
Gracias amigo, muy clara la diferencia que explicas.
La mejor manera de entender algo es con ejemplos del mundo real para poder relacionar el concepto tecnológico con algo que conocemos.
caja negra testing sería el cual una persona haría antes de comprar un coche, encender las luces, encender el motor entre otras pruebas (Sin necesidad de saber cómo funciona el coche por dentro)
realizar pruebas de tipo caja de cristal sería la técnica que usa un mecánico cuando llevas tu coche al mecánico y tiene que buscar una avería.
Fuente: https://www.testermoderno.com/caja-blanca-vs-caja-negra/
Gracias
Por si alguien se pregunta esto, assertEqual() lo que hace es comprar el resultado de tu función con el resultado que tu esperabas, assertEqual(<resultado de función>, <resultado que esperabas>) y si estos dos son iguales, el test es correcto.
Si son iguales regresa True, y si no, regresa False
Gracias!
No se si alguien mas lo noto pero si las funciones declaradas dentro de la clase de unittest no empiezan con test, no se contemplado al momento de hacer las pruebas, por ejemplo si corres el siguiente codigo que en ambas funciones deberia marcar error no te marcara ninguno:
import unittest def mayor_edad(edad): if edad >= 18: return True else: return False class PruebaDeCristalTest(unittest.TestCase): def es_mayor(self): edad = 15 result = mayor_edad(edad) self.assertEqual(result, True) def es_menor(self): edad = 100 result = mayor_edad(edad) self.assertEqual(result, False) if __name__ == '__main__': unittest.main()
Ahora aqui el mismo codigo solo que las funciones empiezan con test:
import unittest def mayor_edad(edad): if edad >= 18: return True else: return False class PruebaDeCristalTest(unittest.TestCase): def test_es_mayor(self): edad = 15 result = mayor_edad(edad) self.assertEqual(result, True) def test_es_menor(self): edad = 100 result = mayor_edad(edad) self.assertEqual(result, False) if __name__ == '__main__': unittest.main()
Espero le sirva este aporte a alguien y sepan que es importante añadir al nombre de la función la palabra test al inicio :)
Sí, lo aprendí al omitir la palabra test por error.
Se debe declarar: def test_nombre_de_funcion(self):
Entonces a que hacer referencia la palabra reservada "self"?
Si alguien desea tener sus apuntes en jupyter notebook o en google colab y correr estas pruebas deben agregar argv=['first-arg-is-ignored'], exit=False al unittest.main() así:
unittest.main(argv=['first-arg-is-ignored'], exit=False)
Aquí de donde extraje la información
Gracias, no sabia por que no corria en Jupyter!!!!!
Hola. La diferencia es que las pruebas de caja negra se realiza teniendo en cuenta los datos de entrada y de salida, sin aun tener una idea de como se va a realizar la lógica del programa, mientras que las pruebas de caja de cristal o caja blanca, como también se le suele llamar, se centra en el procedimiento que tiene el programa, por lo que la implementación de esta prueba esta fuertemente ligada al código que realices. Saludos.
no entiendo cual es la diferencia entre la prueba de cristal y la de la caja negra. noto que ambas se implementan de la misma forma.
Creo que es mas como el concepto, porque si se escriben igual, en la caja negra faltaba codigo por escribir, ayudandote a completarlo y en la de cristal aunque no faltaba codigo esta arrojo el error según la condición que se le habia dado, ayudandote a determinar que esta funcionando mal en el codigo pero no en la escritura sino en las condiciones que diste.
¡Hola!
Las pruebas de caja negra se denominan así por que no conocemos la estructura interna del código, están enfocadas a probar la funcionalidad de la aplicación desde un punto de vista del usuario y son realizadas por ingenieros que no están involucrados en el desarrollo del código.
Las pruebas de caja de cristal o pruebas de caja blanca son aquellas en las cuales conocemos la estructura de código, pueden ser realizadas por ingenieros que están ivolucrados en el desarrollo y son enfocadas en probar cada componente de la aplicación, permite detectar errores de sintaxis, errores de lógica, errores de diseño.
Te recomiendo el Curso de Fundamentos de Pruebas de Software
Cual sería entonces la diferencia con la pruebas de caja negra? Veo que la implementación es igual.
Creo que es mas como el concepto, porque si se escriben igual, en la caja negra faltaba codigo por escribir, ayudandote a completarlo y en la de cristal aunque no faltaba codigo esta arrojo el error según la condición que se le habia dado, ayudandote a determinar que esta funcionando mal en el codigo pero no en la escritura sino en las condiciones que diste.
Hola. La diferencia es que las pruebas de caja negra se realiza teniendo en cuenta los datos de entrada y de salida, sin aun tener una idea de como se va a realizar la lógica del programa, mientras que las pruebas de caja de cristal o caja blanca, como también se le suele llamar, se centra en el procedimiento que tiene el programa, por lo que la implementación de esta prueba esta fuertemente ligada al código que realices. Espero haberte ayudado.
buenas compañeros pueden revisar otros usos e inclusive algunos ejemplos de como se utilizan estas pruebas, y obviamente que más puedes hacer leyendo la documentación de la librería unittest acá: https://docs.python.org/3/library/unittest.html nota está en ingles, pero es la documentación oficial.
Gracias compa!
Excelente aporte
¿Por qué se pone "self" como parámetro?
El parámetro self se refiere al objeto instanciado de esa clase sobre el cual se está invocando dicho método. Es decir, el objeto que usaste para llamar al método.
El parámetro self se refiere al objeto instanciado de esa clase sobre el cual se está invocando dicho método.
Python, dentro de los métodos definidos de una clase, establece que el primer parámetro definido en un método recibirá el objeto con el cual se invoca dicho método. Este parámetro (que se suele llamar self aunque se puede usar cualquier nombre de variable) es usado dentro de la implementación del método para modificar el contenido o atributos de dicho objeto como desees.
Por lo tanto, es una condición necesaria que todos los métodos de una clase que puedan ser llamados a través de un objeto tengan al menos un parámetro, el cual se asignará automáticamente al objeto usado en la invocación.
Aunque en la definición del método, self es el primer parámetro, a la hora de llamar a dicho método no hace falta pasarle el propio objeto como primer parámetro explícitamente ya que Python lo hace de manera implícita sin necesidad de hacerlo manualmente. Es decir, el primer parámetro self del método se asigna automáticamente al propio objeto y el resto de parámetros a los argumentos con que llames al método.
En el caso del método init(), el parámetro self se refiere al objeto recién instanciado de la clase que quieres obtener al crear dicho objeto con Nombre_Clase().
self es el equivalente al this de otros lenguajes (aunque self no es palabra reservada como this), con la diferencia de que en otros lenguajes no hace falta definir los métodos con un parámetro this, mientras que en Python sí es necesario.
Mi recomendación es que no te preocupes por ese parámetro de momento, en el Curso de POO y Algoritmos con Python se profundizará un poco más.
Recuerda, divide y vencerás. ;)
Normalmente los test se corren en archivos aparte? O debería ser parte del código. Osea, si pasa el test, recién se ejecuta la función.
No, por lo general los tests están en archivos apartes, incluso pueden estar separados por carpetas para cuando ya es un programa mucho más grande para así tener mejor organización de archivos.
Acá un articulo que me ayudó a entender:
"Entrando ya de lleno en el tema del testing en la programación pura, que es lo que realmente nos interesa, ¿Cuál sería una definición más concreta del testing en este ámbito? El testing en programación se refiere a la comprobación de que todo el código que se ha escrito funciona.
Por ejemplo, si estamos diseñando una app para pedir taxis, tendremos que comprobar que cuando el usuario abre la app, le aparece un mapa con su posición actual y un botón para pedir un taxi; que al apretar el botón de “pedir un taxi” lo lleva a una pantalla para elegir la hora; que después va a la pantalla de confirmar y que, cuando acaba el viaje, le sale el botón de pagar.
Pero ojo, también probamos si la app responde bien ante los errores. Por ejemplo, que, si no hay taxis, le aparezca el mensaje de error correspondiente; que si no tiene internet le aparezca un mensaje indicándolo; que cuando el pago falla, le aparezca una interfaz para volverlo a intentar."
En Test Development se escriben los Test antes de escribir el código. EN las Pruebas de Caja de Cristal ya existe el código, ya está escrito y se corren los test sobre dicho código, en todos y cada uno de sus módulos y para todas y cada una de las posibilidades del módulo.
import unittest def es_mayor_de_edad(edad): if edad>=18: return False else: return False class PruebaDeCristalTest(unittest.TestCase): def test_es_mayor_de_edad(self): edad=20 resultado=es_mayor_de_edad(edad) self.assertEqual(resultado, True) def test_es_menor_de_edad(self): edad =15 resultado=es_mayor_de_edad(edad) self.assertSetEqual(resultado,False) if __name__ == "__main__": unittest.main()```
Fallaste en esta linea, justo en la segunda funcion del test. **self.assertSetEqual(resultado,False) **
¿Como saber cuando debo utilizar un test de caja negra o de caja de cristal?
La diferencia básica es:
Pruebas de caja negra son implementadas cuando no conoces la estructura interna del código. Son realizadas por ingenieros que no estén involucrados en el desarrollo de la aplicación y tienden a probar la funcionalidad desde una perspectiva del usuario.
Pruebas de caja blanca son implementadas cuando conoces la estructura del código y son realizadas para probar la funcionalidad de todos los componentes internos.
Te recomiendo el Curso de Fundamentos de Pruebas de Software
¿Conoces como funciona cada parte del código a testear y sabes cuál es el flujo del programa y posibles caminos y salidas? Caja de Cristal
¿Conoces que es lo que debería retornar el código, pero no conoces la estructura a detalle? Caja Negra
