Test Agricultores

Resumen clase pasada

Anotamos en el pizarrón los conceptos que hemos incorporado hasta ahora:

  • Trabajo en un lenguaje con chequeo de tipos, los contratos son explícitos
    • clases abstractas: definimos cuáles son, no puedo instanciarlas
    • interfaces
    • métodos abstractos, se deben redefinir en las subclases
  • Tiempo de compilación vs. tiempo de ejecución
  • Extension methods: simulamos el envío de mensajes a clases evitando proliferación de DateUtil, StringUtil, NumberUtil, etc.
  • Diferentes vistas de diseño
    • Objetos candidatos: un boceto para buscar abstracciones
    • Diagrama de clases: en principio distinguimos la asociación (conoce) vs. generalización (hereda de). Diagrama estático.
    • Diagrama de objetos: es una foto en un momento determinado de nuestro sistema. Es un diagrama dinámico.
    • Diagrama de secuencia
    • El código es una herramienta más para documentar mis ideas de diseño. Pero tengo que aprender a ver hasta dónde tiro código.
  • Annotations: meta-datos de un programa, que el compilador puede chequear (ofrece un contrato más fuerte que el simple comentario: @Deprecated vs. "NO USAR")

Hoy nos vamos a concentrar en tres temas nuevos

  • Diseño a partir de los tests (una disciplina que se conoce como Test Driven Development)
  • Cómo automatizar el testeo unitario
  • y por último aprovecharemos para conocer el trabajo con colecciones en XTend.

TDD

  • Es una metodología de desarrollo que consiste en guiar el diseño y la implementación a partir de los casos de prueba.
  • No hay que confundir con automatizar los tests
  • Nosotros no vamos a ser fanáticos: puedo escribir primero el test y después el requerimiento (o hacerlo de la manera tradicional)

Testeo Unitario

  • Ventajas respecto a un main (Verde / rojo vs llenar de printlns)
  • Por qué mejor varios tests y no un único main (o un único test)
  • para programar el test tengo que entender qué necesito y qué espero (el input + la interfaz y el output)
  • Cómo generar casos de prueba: fixtures, efecto colateral
  • el testeo es unitario pero necesito entender algo del negocio para programar el test

Casos de prueba posibles

Juego de datos
  • parcela de 50 hectáreas de soja
  • parcela de 300 hectáreas de soja
  • parcela de 2000 hectáreas de soja
  • parcela de 50 hectáreas de soja transgénica que hace sufrir mutaciones genéticas
  • parcela de 200 hectáreas de soja transgénica que no hace sufrir mutaciones genéticas
  • parcela de 50 hectáreas de trigo que tiene como conservantes glifosato (2 $) y sulfatadina (5 $)
  • parcela de 200 hectáreas de trigo que no tiene conservantes
  • parcela de 40 hectáreas de sorgo
  • parcela de 200 hectáreas de sorgo
Tests
Caso Resultado esperado
Cuánto cuesta cultivar una parcela de 50 hectáreas de soja 500 (50 * 10)
Cuánto cuesta cultivar una parcela de 50 hectáreas de soja transgénica que produce mutaciones genéticas 500 (50 * 10)
Cuánto cuesta cultivar una parcela de 50 hectáreas de soja transgénica que no produce mutaciones genéticas 2000 (200 * 10)
Cuánto cuesta cultivar una parcela de 50 hectáreas de trigo con los conservantes glifosato y sulfatadina 250 (50 * 5 si es menor a 500)
Cuánto cuesta cultivar una parcela de 200 hectáreas de trigo sin conservantes 500 (200 * 5 = 1000, tomando el menor entre 500 y 1000)
Cuánto cuesta cultivar una parcela de 40 hectáreas de sorgo 120 (como son < 50 hectáreas, es 40 * 3)
Cuánto cuesta cultivar una parcela de 200 hectáreas de sorgo 400 (como son > 50 hectáreas, es 200 * 2)
  • El test puede salir
    • ok: precondiciones, acciones y postcondiciones salieron bien
    • falla: no se verifican las postcondiciones
    • error: se produjo un error previo a la verificación (en el armado del juego de datos, en las acciones del test o en la verificación misma)

¿Qué hacer cuando hay un error en los tests?

  • cuando hay un error hay que mirar el stack trace. La pila de ejecución me muestra el encadenamiento de mensajes entre objetos (la peli en el momento en que se rompió todo)
  • otra herramienta que podemos utilizar es el debugger, con él puedo inspeccionar los objetos en runtime, revisar cómo queda el estado del sistema paso a paso, entender qué mensajes se envia a qué objetos y así encontrar un error puntual, pero abusar del debugger induce a trabajar a "prueba y error".
  • una vez que entendí cómo debe funcionar el test, o qué condiciones debo verificar, conviene volver al test, automatizarlo y poder correrlo n veces

Colecciones en xtend

las colecciones nos permiten representar relaciones 1 a n, un conjunto de objetos.

  • colecciones tipadas. Uso de generics: las colecciones admiten tipos parametrizables: puedo decir esta colección es de rabanitos o de clientes.
  • protocolo de colecciones: veremos mensajes que van a ser útiles en la cursada, en particular
    • map
    • fold
    • flatten
    • forEach

y su relación con los objetos bloque

E insistir en algunos temas de diseño:

  • Method lookup: qué pasa cuando envío un mensaje a un objeto. La búsqueda de un método comienza a partir del objeto receptor. Si no existe un método en esa clase, continua buscando en la superclase y así sucesivamente.
  • Cohesión: qué objetivo tiene cada método y cada objeto, los tests detectan baja cohesión. La IDE ayuda a poner cada cosa en su lugar.
  • Acoplamiento: cuánto se conocen los objetos, los tests me ayudan a medir alto acoplamiento
  • Polimorfismo: quién se beneficia, no es el objeto polimórfico sino el que manda mensajes a objetos polimórficos
  • Herencia y qué pasa con los objetos en Runtime

Para el jueves siguiente estaría bueno hablar de:

  • SVN
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License