Processing nos proporciona una manera rápida y sencilla de generar salida gráfica a nuestros programas. Para usarlo basta importar las correspondientes librerias (Ver enlace).
En nuestra clase definimos dos métodos que extienden PApplet.
public void setUp(){
// Aqui preconfiguramos la salida, inicializamos objetos,..
}
public void draw(){
// Este metodo es el encargado de dibujar la salida, por lo que se ejecuta continuamente.
Reflexión (reflection) es un framework habitualmente poco conocido. Este framework nos permite preguntar al código por si mismo.
Aunque su uso no sea muy conocido, a nivel interno componentes como Hibernate lo usan.
Un ejemplo más cercano es la programación de servlets dentro de una pagina web dinámica.
En el fichero web.xml, podemos indicar a reflection como “generar la clase”.
Un ejemplo de lo anterior es el siguiente:
<servlet>
<servlet-name> Nombre </servlet-name>
<servlet-class> Nombre fichero java</servlet-class>
<servlet>
<servlet-mapping>
<servlet-name> Nombre </servlet-name>
<servlet-pattern> Nombre fichero java</servlet-pattern>
<servlet-mapping>
Reflecttion se encuentra dentro de java.lang.Object con lo que todos los objetos pueden hacer uso de él.
Reflection nos proporciona los siguientes métodos:
public String getName()
public Class getType()
public Object get(Object obj)
public void set (Object obj, Object value)
public Class[] getParameterTypes()
public Cass getReturnType()
Si bien mediante estos métodos reflexión solo obtiene los campos y métodos públicos de una clase. A través de los métodos constructores, getters y setters podríamos obtener información suficiente para reconstruir la clase o bien interactuar con ella con la suficiente seguridad de la corrección.
2. m. Ling. Cada uno de los esquemas formales en que se organizan las palabras nominales y verbales para sus respectivas flexiones.
3. m. Ling. Conjunto cuyos elementos pueden aparecer alternativamente en algún contexto especificado; p. ej., niño, hombre, perro, pueden figurar en El -- se queja.
Laprogramación orientada a objetosoPOOes unparadigma de programaciónque usaobjetosy sus interacciones, para diseñar aplicaciones y programasinformáticos. Está basado en varias técnicas, incluyendoherencia, abstracción,polimorfismoyencapsulamiento. Su uso se popularizó a principios de la década de los años 1990.
La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:
Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
Herencia:por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.
Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
Evento: Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.
Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.
Componentes de un objeto: atributos, identidad, relaciones y métodos.
Identificación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.
Una consideración al hacer uso de la librería TestNG, es que la distribución de los paquetes debe ser simétrica.
Ejericio | |SRC|---principal | | |TEST|-principal
Las clases pruebas se haran dentro de la carpeta Test y el paquete principal. Esta manera de organizar los archivos permite desde la carpeta de pruebas acceder a las clases principales sin necesidad de import y demás consideraciones de la privacidad
Mientras que en la entrada anterior nos centrábamos en los parámetros de entrada y salida de una clase y lo que nos devolvía, en este tipo de pruebas lo que nos va a interesar es como se relacionan entre si las clases. Las pruebas de caja blanca o caja transparente son más exigentes que las de caja negra, ya que se concentran en la forma en que el programa realiza su funcionalidad para lograr el resultado, y no en el resultado en sí. Haremos uso de la librería Mockito Mockito nos permite crear "objetos simulados", que interactuen con nuestro objeto, sin necesitar de implementarlos.
Se siguen los siguientes pasos:
1.Definir el objeto a probar. 2.Definir la relación entre el objeto simulado (mock) y nuestra clase. 3.Invocación 4.Comprobación de resultados y comportamientos
Siguiendo el ejemplo anterior de la venta de entradas, tenemos la clase Cine que debe comunicarse con el servicioAsignacionButaca, la clase servicioAsignacionButaca carece de implementación, solo conocemos en cine los métodos de dicha clase que vamos a necesitar.
1.Definir el objeto a probar. Cine cine=new Cine() ServicioButaca servicioButacaMock=mock(ServicioButaca.class);
2.Relación entre objetos cine.servicioButaca=servicioButacaMock
3.Invocación. cine.reservaEntrada(Pelicula,Fecha) //reservaEntrada(..) hace uso del metodo reservaButaca de la clase "mockeada";
4.Comprobación de resultados verify(ServicioButacaMock).reservaButaca(pelicula,fecha)
El uso de mocks no sólo permite verificar la comunicación. Tenemos opciones adicionales para el control de excepciones o los valores de retorno de una función.
Las pruebas de caja negra, no tienen en cuenta el funcionamiento interno del programa, sino unicamente el resultado de las comunicaciones entre objetos. Dichas interacciones se verifican mediante el uso de asserts.
Un assert es una condición que se debe dar en un programa para que no se produzca un error.
Esta metodología de diseño garantiza que una clase en particular se comporte de una forma en particular.
Mediante esta metodología y a través del uso del desarrollo dirigido por pruebas, podemos garantizar ese comportamiento en concreto. Para realizar las pruebas hacemos uso de la librería TestNg
En esta metodología seguimos el siguiente proceso:
1Elegir un requerimiento
2Escribir una prueba:
3Verificar que la prueba falla:
4Escribir la implementación: Escribir el código más sencillo que haga que la prueba funcione. Se usa la metáfora "Déjelo simple" ("Keep It Simple, Stupid" (KISS)).
5Ejecutar las pruebas automatizadas:
6Eliminación de duplicación: eliminar código repetido.
7Actualización de la lista de requerimientos:
A modo de ejemplo:
Tenemos la siguiente clase, public class Taquilla{...};
La taquilla tiene el método Entrada:ventaEntrada(Pelicula,Fecha)
Sean los comportamientos deseados:
- Si la Pelicula no se proyecta lanza excepcion RuntimeException("La pelicula no se emite")
- Si la Fecha es anterior a hoy lanza excepcion RuntimeException("Fecha incorrecta")
- Si la película se emite y la fecha es correcta devuelve una entrada.
El proceso de diseño de la prueba sigue los siguientes pasos:
1.Nombre de la prueba.
public class VentaEntradasTest
2. Nombre del método
@Test
public void ventaEntradas()
3.Definir el objeto a probar.
Taquilla taquilla=new Taquilla();
4. Escenario de la prueba
Cine cine=new Cine();
Date hoy=new Date(YYYY,MM,DD)
/*El cine debe contener películas
Es necesario en este paso compilar, ver lo que falla, comunicar métodos.
Inicializar el escenario
*/
5.INVOCACION
entrada=ventaEntrada(Pelicula,fecha);
6.COMPROBACIÓN RESULTADOS Y MENSAJES ERROR
Con el uso de assert podemos verificar los resultados y dar los mensajes de error correspondientes.
En esta fase se escribe el minimo código necesario para que la prueba pase.
