Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IWT2 Dojo US. Introducción a TDD. 5 octubre 2012

1,662 views

Published on

Introducción a Test-Driven Development y los videojuegos presentada en el IWT2 Dojo US el 5 de octubre de 2.012

Published in: Education
  • Be the first to comment

IWT2 Dojo US. Introducción a TDD. 5 octubre 2012

  1. 1. Desarrollo deVideojuegos Dirigido por PruebasTDD for Games Development
  2. 2. Desarrollo de Videojuegos Dirigido por Pruebas • Aprender los conceptos claves de TDD. • Aprender conceptos clave de los videojuegos. • Ver cómo aplicar TDD en la programación de un videojuego. • Estudiar un ejemplo práctico. Objetivos 2
  3. 3. Resumen de la Charla 3
  4. 4. Resumen de la Charla • Programar un juego muy sencillo usando TDD. • Explicaremos primero TDD • Usaremos LUA y Löve (ideas aplicables a otros entornos). • NO entraremos en detalles de LUA ni Löve. 4
  5. 5. Resumen de la CharlaDemasiado Constante Variable no rápido equivocada declaradaFaltan enemigos Mala lógica 5
  6. 6. Resumen de la Charla• LUA: http://www.lua.org/• Programming in LUA: http://www.lua.org/pil/• Löve: https://love2d.org/• Código fuente: e-mail• Curso TDD desde cero:http://www.iwt2.org/opencms/opencms/IWT2/formacion/catalogo/curso0006.html?locale=es
  7. 7. 03. TDD 1. Resumen. 2. Conceptos generales 3. El Proceso TDD 4. TDD + Videojuegos 5. Comenzando un juego en TDD 6. Un ejemplo más avanzado 7. ConclusionesÍndice 7
  8. 8. Conceptos Generales 8
  9. 9. Definiciones• ¿Qué es probar? Para probar un programa tenemos que ejecutarlo. Verificación dinámica del La prueba tiene un límite. comportamiento del software a partir de un conjunto finito de casos de No vale ejecutar el prueba. programa de cualquier manera.
  10. 10. Definiciones Ejemplos de casos de pruebas en el mundo real¿Funciona el teléfono?. Valores de Acciones Resultado esperado prueba123-45-67-89 1. Descolgar auricular. (Pepote): “Digameee”. 2. Marcar número de Pepote. 3. Esperar contestación.¿Me está bien esta camisa? Valores de Acciones Resultado esperado pruebaMi cuerpo. 1. Ponerme la camisa. Elegancia y confort. 2. Abrochármela. 3. Moverme un poco. 4. Mirarme al espejo. Cuidado con la etiqueta o con arrugarla por si hay que devolverla
  11. 11. Definiciones Necesidades Verifican de los Pruebas de aceptaciónQué se prueba. usuarios Verifican Paso a Pruebas de producción implantación Pr ba oc ue e Verifican so pr Requisitos del Pruebas de de sistema sistema de so de e s oc arr Pr oll Interacción Verifican Pruebas de o entre integración componentes Componentes Verifican Pruebas aislados unitárias Ensamblado Necesidades Requisitos del Paso aCódigo fuente de de los componentes sistema producción usuarios Momento de realizarla Pruebas Pruebas de Pruebas de Pruebas de Pruebas de unitarias integración sistema implantación Aceptación Ejecución de las pruebas
  12. 12. Definiciones• Pruebas unitarias: – Cuando: Durante la construcción del sistema – Objetivo: Comprueban la correcta unión de los componentes entre sí a través de sus interfaces, y si cumplen con la funcionalidad establecida .• Ejemplo: – Combinar el código de acceso a la base de datos con el código de lógica de negocio y probar que funciona correctamente.
  13. 13. Definiciones• Pruebas de aceptación – Cuando: Después de la implantación en el entorno de producción – Objetivo: Verifican que el sistema cumple con todos los requisitos indicados y permite que los usuarios del sistema den el visto bueno definitivo.• Ejemplo: – Que el sistema pueda realizra una venta correctamente (ahora en el entorno de producción).
  14. 14. Pruebas con LUA Veamos un ejemplo muy sencilloValores de Acción Resultado prueba 2, 3 Suma(2,3) 5 -1, 0 Suma (-1, 0) -1 … … …
  15. 15. El Proceso TDD 15
  16. 16. El Proceso TDDNo pensamos en qué software / código tenemos que construirPensamos en cómo queremos usarlo El cómo usarlo nos las dan las No la diseñó quien la pruebas. Las pruebas son las iba a utilizar usuarias de nuestra creación
  17. 17. 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
  18. 18. 2. El Proceso TDD• Estamos tomando decisiones .• Decisiones sobre cómo crear un carrito: ¿cuál es el nombre de la clase? ¿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? Antes de escribir• Decisiones sobre cómo comprobamos que el carrito ha el código almacenado el producto. ¿qué pensamos cómo métodos incluimos,? ¿cuáles el queremos usarlo. resultado esperado? ¿Hay que escribir antes una prueba para dicho método? 18
  19. 19. 2. El proceso TDD El proceso de TDDEs decir, los pasos que vamos dando para ir escribiendo nuevo código Veamos un ejemplocompleto paso a paso
  20. 20. 2. El Proceso TDD Veamos un ejemplo. Vamos a sumar dos números enteros. Lo primero según TDD, es escribir una nueva prueba No tenemos enValores de prueba Acción Resultado cuenta valoresA, b cuáles quiera Suma(a, b) a+b extremos … … …
  21. 21. 2. El Proceso TDDAutogeneramos el código que falta con Eclipse para poder ejecutar la prueba.Escribimos el código mínimo (más corto) para que la prueba pase con éxito
  22. 22. 2. El Proceso TDD ¿Qué podemos refactorizar en este ejemplo?Nombres más descriptivos para los parámetrosArreglar atajos del código queno requieren más pruebas
  23. 23. Código mínimo para Pasar una Prueba• ¿Cómo escribir una prueba para un código que no existe?• Escribe una prueba para el código que te gustaría que existiera. – Hazlo tan simple como quieras. – Con los parámetros y tipo devuelto que más fácil te hagan el trabajo.
  24. 24. TDD + Videojuegos 24
  25. 25. ¿Esto se aplica a videojuegos? Resolviendo niveles automáticamentehttp://www.youtube.com/watch?v=DlkMs4ZHHr8 http://www.youtube.com/watch?v=NOTBy0lKSbo
  26. 26. ¿Esto se aplica a videojuegos?
  27. 27. ¿Esto se aplica a videojuegos?
  28. 28. Comenzando un videojuego con TDD 28
  29. 29. ¿Qué queremos conseguir?
  30. 30. ¿Qué queremos conseguir?
  31. 31. Framewrok: Löve + LUA Dt es el delta-time o tiempo entre dos llamadas. Lo usamos para adaptar la velocidad del juego a la máquina Vamos a implementar estos métodos para realizar el juego anteriorSólo con escribir estos tres métodos ya tenemosjuegos.Aproximadamente 150 líneas de código.
  32. 32. ¿Por dónde empezamos?• Nuestro primer paso no va a ser muy distinto del segundo, Un jugador que se mueva. el tercero, etc. definimos una prueba de aceptación. Disparos• No vamos a intentar hacer Enemigos que se muevan todo el juego de golpe, pero sí elegiremos una Colisión de disparos y enemigos. característica que tenga valor y relevancia en el juego. Fin del juego• Apuntemos las candidatas:
  33. 33. TDD en Juegos • Ten siempre una lista deUn jugador que se características o requisitos demueva. código.Disparos • Eso son cosas que se te vanEnemigos que se ocurriendo cuando escribesmuevan pruebas y escribes código para superar las pruebas.Colisión de disparos yenemigos. • Te ayuda a no tener cosas en la cabeza y céntrate en seguirFin del juego tu foco • Te indican qué es lo siguiente a realizar
  34. 34. TDD en JuegosUn jugador que semueva.DisparosEnemigos que semuevanColisión de disparos yenemigos.Fin del juego
  35. 35. TDD en JuegosUn jugador que semueva.DisparosEnemigos que semuevanColisión de disparos y Un fondo negroenemigos. Un cuadrado rojoFin del juego El cuadrado en el centro y en la parte baja de la pantalla Si pulso  mueve a la derecha Posibles pruebasmueve a la Si pulso 
  36. 36. TDD en JuegosEscribimos el esqueleto d enuestro primer conjunto de pruebas 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
  37. 37. TDD en JuegosEjecutamos prueba y falla. Sólo necesitamos una línea para arreglarlo en el archivo main.lua: BgColor = {}
  38. 38. ¿Por dónde empezamos?Un jugador que semueva.DisparosEnemigos que semuevanColisión de disparos y Un fondo negroenemigos. Un cuadrado rojoFin del juego El cuadrado en el centro y en la parte baja de la pantalla Si pulso  mueve a la derecha Posibles pruebasmueve a la Si pulso 
  39. 39. ¿Por dónde empezamos?Escribimos el esqueleto de nuestro primer conjunto de pruebas Un fondo negro Falla Un cuadrado rojo El cuadrado en el centro y en la parte baja de la pantalla Si pulso  mueve a la derecha Pasa Si pulso  mueve a la izquierda Decidimos el diseño.
  40. 40. Un ejemplo más avanzado 40
  41. 41. Un ejemplo más avanzado Los aliens mueven en una dirección. Cuando el primer alien llega al borde de la pantalla, todos bajan hacia abajo y mueven en otra dirección Cuando llegan al límite inferior se acaba el juego¿Cómo quierohacerlo?
  42. 42. Un ejemplo más avanzadoCrear a los aliens Estamos probando este escenarioPero podemos probar Escribimos nuevas otros escenarios pruebas para escribir el código
  43. 43. Un ejemplo más avanzado Aliens[1..8]Aliens[9..16] Aliens[33..40]
  44. 44. Un ejemplo más avanzadoValores de prueba (*) Acción Resultado esperadoD = Der Mover en la dirección Todos los aliens hanAmE. X < Límite incrementado su X en 1.AmB.Y < LímiteD = Der Cambiar dirección y D = Izq.AmE. X == Límite bajar Todos los aliens hanAmB.Y < Límite incrementado su Y en 1.D = Der Mover en la dirección Todos los aliens hanAmE. X < Límite incrementado su X en 1.AmB.Y < Límite… … …Lo que influye en el movimiento es la dirección, altura (coordenada Y) del alien más bajo y la coordenada X del alien más en el extremo
  45. 45. Un ejemplo más avanzado
  46. 46. Un ejemplo más avanzado
  47. 47. Un ejemplo más avanzadoEste método ya está terminado. Pasamos a otra tarea.
  48. 48. Conclusiones 48
  49. 49. Conclusiones• Fallos que tengo escribiendo juegos. – Escribo más nombres de variables (y se crean nuevas variables sin yo saberlo) – Me equivoco en operaciones aritméticas (sumas, restas, etc.) – Me equivoco utilizando constantes – Utilizo variables que, en otra parte del código, dejer de utilizar – A veces no sé si se está entrando en un if o ejecutando un código determinado. – En general, LUA escala mal.
  50. 50. Conclusiones El proceso de TDDEs decir, los pasos que vamos dando para ir escribiendo nuevo código
  51. 51. Conclusiones10.000 líneas de código C#...Comprobado…. 124 assemblies .NET Ahora que mis pruebas unitariasgenerados…. Comprobado…. 52 están escritas puedo empezar ascripts de construcción… construir mis componentes.comprobado

×