TDD y Python
•Transferir como PPTX, PDF•
3 gostaram•1,534 visualizações
Una visión global de cómo aplicar Test-Driven Development en Python
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a TDD y Python
Semelhante a TDD y Python (20)
Mais de Javier_J
Mais de Javier_J (16)
TDD y Python
- 3. 3 • Aprender los conceptos claves de TDD. • Empezar a practicar haciendo TDD con Python. • Realizar un ejercicio de TDD guiado. 03. T.D.D. Objetivos
- 4. 4 1. Una idea intuitiva 2. El Proceso TDD 3. Buenas Prácticas en TDD 4. Ejemplo. 5. Extra 6. Kata ¿? 03. TDD Índice
- 6. 6
- 7. 7 Una idea intuitiva Constante equivocada Mala lógica Variable no declarada Faltan enemigos Demasiado rápido
- 11. 1. El Proceso TDD • Suponemos que estamos escribiendo una prueba para una clase que funciona como un carrito de la compra que aún no ha sido escrita. • Veamos un posible caso de prueba
- 12. 12 • Estamos tomando decisiones de diseño: • Decisiones sobre cómo crear un carrito: ¿cuál es el nombre de la clase X? ¿Tendrá un constructor sin parámetros? • Decisiones sobre añadir elementos: ¿Usaremos una llamada a un método? ¿cuál será el nombre de ese método? ¿Qué parámetros tendrá y de qué tipo serán? 2. El Proceso TDD • Decisiones sobre cómo comprobamos que el carrito ha almacenado correctamente el producto. ¿qué métodos incluimos,? ¿cuáles el resultado esperado? ¿Hay que escribir antes una prueba para dicho método? Antes de escribir el código pensamos cómo queremos usarlo.
- 13. 2. El Proceso TDD El proceso de TDD Es decir, los pasos que vamos dando para ir escribiendo nuevo código Veamos un ejemplo completo paso a paso
- 14. 2. El Proceso TDD Escribimos un test que ponga de relieve funcionalidad que queremos implementar Si la prueba no falla estudiamos qué está sucediendo y elegimos otra. Escribimos el código mínimo (más corto) para que la prueba pase con éxito. No nos preocupamos de escribirlo bonito, tenemos libertad para tomar atajos
- 15. 2. El Proceso TDD Ejecutamos la prueba y cambiamos el código hasta que la prueba funciona. Quitamos los atajos y refactorizamos el código y las pruebas. Triangulando, completando el conjunto de pruebas o eligiendo una nueva funcionalidad. Y cómo continuamos?
- 17. Buenas prácticas en TDD 1. Código mínimo (prueba y código). 2. Triangular. 3. Diario de diseño. 4. Buenas herramientas de prueba (mocks). 5. Saber de pruebas. 6. Utilizar patrones de diseño y de pruebas 7. Principios SOLID y GRASP. 8. Usa las herramientas adecuadas
- 18. Buenas prácticas en TDD Código mínimo (prueba y código).
- 19. Buenas prácticas en TDD ¿Qué quiero cambiar? Hacer el cambio Prepararlo para más cambios Triangular.
- 20. Buenas prácticas en TDD Diario de diseño. Un fondo negro Un cuadrado rojo El cuadrado en el centro y en la parte baja de la pantalla Si pulso mueve a la derecha Si pulso mueve a la izquierda
- 21. Buenas prácticas en TDD Diario de diseño.
- 22. Buenas prácticas en TDD Mocks, Spyes, Doubles, Stubs, etc. User Pedido Descuentos Database Self Descontar
- 23. Buenas prácticas en TDD • Análisis de caminos • Particiones equivalentes. • Valores límite. • Método Categoría-Partición • Pruebas de integración • Pruebas de requisitos no funcionales. Saber de pruebas.
- 24. Buenas prácticas en TDD Utilizar patrones. (arquitectónicos, de diseño, de prueba, de implementación, todos ) Creation Method
- 25. Buenas prácticas en TDD Principios SOLID y GRASP (fuente: http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife).
- 26. Testing en Python http://wiki.python.org/moin/PythonTestingToolsTaxonomy Unittest, Doctest. Nose Mockito for Python, Mocker, Pydoubles Selenium, Django Testing Behave, PyFIT, Lettuce
- 27. 27 Ejemplo para entrar en calor
- 28. Ejemplo Un generador que devuelva los números pares: 2, 4, 6, 8,…. Nada que refactorizar: ni código ni pruebas. Para continuar necesitamos más pruebas
- 29. Ejemplo Un generador que devuelva los números pares: 2, 4, 6, 8,….
- 30. Ejemplo Evitar el código repetido (sobre todo el que puede cambiar)
- 31. Ejemplo ¿Pero esto de verdad funciona? Probemos…... Pero esto no es TDD
- 32. 32 Extra
- 33. 33 Extra Para saber más de TDD.
- 35. 35 Extra Ejemplo de mocks en Python http://iwt2- javierj.tumblr.com/post/36695988608/mocks-en- python-previa-python-tdd
- 36. Extra 10.000 líneas de código C#... Comprobado…. 124 assemblies .NET generados…. Comprobado…. 52 scripts de construcción… comprobado Ahora que mis pruebas unitarias están escritas puedo empezar a construir mis componentes. Según lo que hemos visto en este módulo, ¿qué está haciendo mal nuetsro programador?
- 37. 37 Extra Es difícil pero se puede
Notas do Editor
- Vamos a empezar viendo una idea intuitiva de la filosofía de TDD. Si alguna vez hemos escrito un programa seguro que captamos la idea enseguida.
- A todos nos ha pasado que entramos en un bucle corrección- ejcución – comrobación a man. Esto quema mucho 8muy repetitivo), perdemos tiempo y, si más adelnate vuelve a fallar lo que arreglamos nos desmoralizamos. Esto pasa sobee todo en los videojuegos ya que la percepciones: gráficos, jugabilidad, etc. son tan importantes. Sin embargo sí que podemos ahorrarnos trabajo (aunque al principio parezca que trabajamos ,ás) haciendo que el código compruebe al código. Con esto tenemos unos cimientos para ir avanzando.
- Si hemos escrito algún programa o código, seguro que se nos ha quedado la idea e que, si lo volviéramos a hacer justo al terminarlo, lo habríamos hecho muchísimo mejor. Eso es porque ya hemos descubierto no solo cómo hacerlo, sino también cómo queremos utilizarlo. Vamos dando pasos muy pequeños para segurarnos d elo que funciona y lo que no.
- Una vez vista la idea intuitiva vamos a definir de manera formal TDD, y cómo lo aplicaremos a lo largo de todo el curso para diseñar nuestro código.
- Si nos fijamos, en la prueba ya hemos tenido que tomar un conjunto de decisiones que tienen un impacto muy grande sobre el código que tendremos que escribir (en este caso la clase carrito). Piensa en esas decisiones ante de pasar a la siguiente transparencia.
- Las primeras decisiones que tomamos al escribir una prueba es ¿cómo creamos un objeto carrito? ¿cuál es el nombre de la clase carrito? ¿tendrá un constructor sin parámetros? Después tendremos que seguir tomando decisiones , por ejemplo cómo añadimos elementos al carrito. ¿Usaremos una llamada a un método? ¿cuál será el nombre de ese método? ¿Qué parámetros tendrá y de qué tipo serán? Estas decisiones son el diseño de nuestro código, nos condicionan como lo usaremos, la facilidad para modificarlo y probarlo y la claridad a la hora de repasarlo más adelante (incluso por otras personas). Por ello, todas estas decisiones son muy importantes.
- El proceso de TDD consiste en hacer lo que hemos visto en las dos transparencias anteriores y utilizar las pruebas para que nos ayuden a tomar las decisiones de diseño de código más adecuadas. Todo TDD se resume en esta imagen. Veamos la película completa y, a continuación, veremos cada elemento con más detalle. Primero centramos nuestro foco: ¿en qué vamos a trabajar a continuación? ¿acceso a datos? ¿validaciones? ¿diseñar nuevas clases? ¿implementar lógica de negocio? Una vez que hemos elegido lo que haremos a continuación y teemos claro el objetivo a conseguir, creamos una prueba. (completar).
- Si este ejemplo te parece trivial, tienes razón. Pero queremos que te centres en aplicar TDD y no en porblemas de programación. Ya verás como los ejercicios son bastante más elaborador. La mejor manera de aclarar las ideas e smediante un ejemplo muy muy sencillo. Tieens disponible el código del ejemplo en la plataforma virtual. ¿Por qué no vas haciendo el ejemeplo paso a paso en Eclipse? Recuerda que aquí hemos tenido que decidir cómo se llama la clase, como se crean objetos, como se lláma el método, cuáles son sus parámetros y tipo devuelto, etc..
- Falta el código en esta transparencia.
- El diario de diseño es una herramienta muy útil también cuando utilizamos TDD. Este diario no e smás que la lista de tareas que tenemos endientes de hacer, por lo general código a escribir o funcionalidad a implementar. El principal objetivo es mantenernos en todo momento con el foco centrado. ¿No te ha pasado nunca que te has concentrado mucho en escribir una prueba y luego no recordabas muy bien qué querías implementar? El diario nos ayudará con esto. Veremos todo esto con más detalles y ejemplos justo a continuación.
- ¿Sabías que vas a pasra más tiempo leyendo código y modificándolo que excribiéndo código nuevo?
- Razones para escribir el mínimo código posible (aunque parezca que no tiene valor). Realmente estamos diseñando el código, no codificando. Estamos escribiendo pruebas para todo nuestro código, si escribimos código más complejo, este no estará probado. Podemos tener algo que se ejecute, y se pruebe, my rápido.
- Tenemos que tener centrado el foco en lo que qeremos probar, pro eso tomamos notas d elas cosas que van surgiendo y que hay que hacer. No confundir esto con los requisitos Documental Indy Game El diario de diseño es una herramienta muy útil también cuando utilizamos TDD. Este diario no e smás que la lista de tareas que tenemos endientes de hacer, por lo general código a escribir o funcionalidad a implementar. El principal objetivo es mantenernos en todo momento con el foco centrado. ¿No te ha pasado nunca que te has concentrado mucho en escribir una prueba y luego no recordabas muy bien qué querías implementar? El diario nos ayudará con esto.
- Tenemos que tener centrado el foco en lo que qeremos probar, pro eso tomamos notas d elas cosas que van surgiendo y que hay que hacer. No confundir esto con los requisitos Documental Indy Game El diario de diseño es una herramienta muy útil también cuando utilizamos TDD. Este diario no e smás que la lista de tareas que tenemos endientes de hacer, por lo general código a escribir o funcionalidad a implementar. El principal objetivo es mantenernos en todo momento con el foco centrado. ¿No te ha pasado nunca que te has concentrado mucho en escribir una prueba y luego no recordabas muy bien qué querías implementar? El diario nos ayudará con esto.
- ¿Cómo porbarías este método? No devuelve nada Necesita al menos cuatro objetos adicionales: databse, user, pedido, descuentos ¿Tengo que tenerlos ya implementados y probados? La solucióne s aplicar mocks. < definiciónd e mocks >
- A la vista de un código, ¿cómo sé qué tengo que probar? ¿Cómo sé cuáles son las pruebas relevantes y las repetidas? << Buscar una imagen que vaya en esta línea >>
- En este ejemplo estamos aplicando el patrón de prueba Creation Method documentado en el libro xUnit Test Patterns Este patrón en concreo se utiliza para ocultar los detalles de la creación de objetios a la prueba y tenerlos localizados en un único punto de cambio, ya que estos detalles por ejemplo los constructores) pueden ir cmabiando en la construcción incremental del código
- Si no hemos utilizado TDD uno de los principales diferencias es que muchas de las clases que surgen no las decidimos nsootros sino que surgen en las refactorizaciones. Para identificar claramente cuando hemos de crear una nueva clase y dónd eponer los nuevos métodos que van suriendo utilizamos los principios SOLID y GRASP
- Elegir la herramienta de tetsing adecuada. Pydoubles:
- Es importante que todos usemos ls mismas palabras para referirnos a los mismos conceptos.
- Lo cambios que hagamos al código deben seguir haciendo que la primera prueba funcione. Si no, paramos, escribimos una prueba como queremos que sea el código, la pasamos y continuamos.
- ¿Por qué esto no es TDD? Porue no estoye scirbiendo una prueba para que falle y añadir una nueva prueba. ¿Es malo escribir pruebas sin hacer TDD? No. ¿Es malo añadir esta prueba? Puede, ya que esta prueba hace lo mismo que las otras. Sirve para darnos sgeuridad peor no busca un error que no bsuque las anteriores. Es c´doigo redundánte que dbeería quitarse en el omento en que haya que mnatenerlo.
- Hora de poner en práctica todo lo aprendido.
- Comparte tus comentarios a esta viñeta en los foros del curso.