Resumen Clase 2

Resumen de la clase 2

Repasamos el enunciado de las obras sociales de la clase 1.

¿Por qué necesitamos un IDE? Porque nos ofrece un montón de facilidades a la hora de desarrollar (y de diseñar), por ejemplo, la capacidad de renombrar una clase o cambiar la firma de un método en forma automática, cosa que sería inpensable si trabajaramos con un editor de texto y compiláramos a mano. Nos permite tomar decisiones y que después un cambio de rumbo no sea catastrófico.

El enunciado nos dice que la Ambulancia no puede tener más de una persona asignada, para cumplir este requerimiento vamos a armar un test unitario que valide esa situación.
Pero, ¿qué es un test unitario?, es una forma de validar una pequeña parte de mi código. Yo preparo mis objetos y digo lo que debería pasar cuando le pido algo a alguno de ellos, si eso no pasa, el test falla.

Un test unitario debe tener 3 características:
* Automático, no necesito estar mirándolo para ver que todo este bien.
* Repetible, puedo correrlo todas las veces que quiera, y mientras no cambie el código, el resultado es el mismo.
* Independiente, no puede depender de otros tests, ni dejar "sucio" el ambiente.

Más detalles en el Apunte de Testing

¿Cómo lo hago?
Usamos JUnit, un framework de unit testing para Java, el cual nos pide que armemos nuestros tests con una estructura como esta:

@Test
public void testLoQueQuieroTestear() {
    //preparo mis objetos
    Ambulancia ambulancia = new Ambulancia();
    //hago lo que me interesa
    ambulancia.encender();
    //me aseguro que mis objetos estan como deberian (Assert)
    Assert.assertTrue(ambulancia.estaEncendida());
}

Ese @Test es un Annotation, es simplemente una marca que yo dejo en mi código, que no modifica el comportamiento de mis objetos, y sirve para que después alguien venga, las lea, y pueda decidir algo.
En el caso de los test, JUnit es quien va a leer los annotations de mis clases, va a ver que un método esta marcado como @Test, y lo va a ejecutar.

También vemos que, cuando llamo a mis objetos, esa invocación puede terminar de distintas formas:
* Sin retornar nada, cuando el mensaje es void
* Con un valor de retorno, por ejemplo un boolean u otro objeto
* Con una excepción

Las excepciones son una forma de realizar manejo de error, cuando un objeto no puede hacer lo que le pidieron y no sabe que más hacer, puede tirar una excepción. Esto corta la ejecución del programa, y vuelve hacia atrás en la cadena de llamados hasta que alguien la atrape.

Entonces, en ningún caso debo retornar null, imprimir un mensaje por pantalla, o pedirle cosas al usuario: hago lo que debo hacer, o termino con excepción.

Hay toda una jerarquía de excepciones, desde Throwable hacia abajo. Nos interesan las Exception, y en particular, aquellas que hereden de RuntimeException. En el TP conviene utilizar nuestras propias excepciones, que hereden de esta última.
Para más detalle tenemos el Apunte teórico - Manejo de Errores.

Una cosa más sobre testeo unitario, hay algunos chiches de JUnit que pueden hacer mi código de tests más claro:
* @Before, le dice a JUnit que corra este método antes de CADA test marcado con @Test. Generalmente lo usamos cuando queremos limpiar (o crear de nuevo) un objeto que usamos en varias pruebas.
* @After, al igual que el anterior, pero después de cada @Test. Por si un test puede llegar a ensuciar el entorno.

Clase 2

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