Ejemplos de una aplicación de manejo de contactos con Kotlin y JPA. Usando para testear la aplicación JUnit 5 y Mockito. Almacenamiento en base de datos relacional H2.
Este ejemplo de clase pensado para Acceso a Datos, muestra como consumir una base de datos relacional usando JPA con Hibernate. Además se ha mostrado el uso de JUnit 5 y Mockito para testear algunos elementos. Finalmente tambien se mapean objetos y se convierten a JSON para entrada y salida de la información.
En persona puede tener dirección o no, incluso varias direcciones. De la misma manera puede tener o no tener uno o varios teléfonos. Una dirección en un instante solo puede estar ocupada por una persona, y un teléfono sólo pertenece a una persona.
Además, dada una persona sabremos su direcciones y teléfonos, si los hay, pero también dada una dirección necesitamos saber qué persona vive allí. (Por ejemplo, si una persona tiene una dirección en Madrid, podemos saber a qué persona esa dirección pertenece). Para los teléfonos no es el caso.
Se implementa una arquitectura basada en Controlador -> Servicios -> Repositorio, siguiendo los ejemplos vistos en clase. Nos centramos en Persona, aunque gracias a JPA, al pasar un objeto persona con sus datos completos se insertan los datos correspondientes en las tablas indicadas según el diseño de objetos.
Para la persistencia de datos se usa JPA junto a Hibernate usando una Base de Datos Relacional en memoria H2. Puedes consultar más en el siguiente enlace: https://www.baeldung.com/learn-jpa-hibernate
Para testear se ha usado JUnit 5 para crear pruebas unitarias. Estas se han aplicado en el repositorio principalmente. Además, hemos complementado estas pruebas usando Mockito. Su uso principal se puede ver en Servicios, donde se mockea el repositorio. El controlador se ha testeado usando solo JUnit 5. Por supuesto que se puede hacer mokeando el servicio, pero lo dejo como ampliación o ejercicio de clase para que el alumnado pueda hacerlo y practicar. Ahora mismo al usar solo usa JUnit, estamos integrando las llamadas a todas las clases y por lo tanto vemos como se encadenan las llamadas entre unas y otras. Estas es una gran diferencia sustanciar respecto al uso de mock, que siempre que sea posible es una opción más aceptable, pues pruebas tu clase sin depender "directamente" de la ejecución del resto. Como he dicho, si no mockeamos, estamos integrando en las pruebas unitarias entre capas de nuestras arquitectura.
Codificado con 💖 por José Luis González Sánchez
Cualquier cosa que necesites házmelo saber por si puedo ayudarte 💬.
Este proyecto está licenciado bajo licencia MIT, si desea saber más, visite el fichero LICENSE para su uso docente y educativo.