Se ha implementado el modelo de resultado con el ORM Doctrine y la aplicación web con swagger y el potentísimo framework de Symfony con todas las operaciones demandadas en la práctica.

Con dos operaciones añadidas:

• GET /results/bigger : solicita un valor y devuelve la lista de resultados que tienen un valor mayor.
• GET /results/number : devuelve el numero de resultados registrados.

Cada Resultado almacena el usuario que lo registró, junto a su fecha y valor.

Se han implementado las pruebas adaptadas a la entidad Result y a las funcionalidades de la API que trabajan con ellos, a continuacción se presentan las imagenes del resultado de la ejecucion de las pruebas con:

php bin/phpunit --testdox

He de comentar que no he conseguido controlar el flujo de ejecución de algunos tests, por lo que hay dos test, dependientes de la creación y borrado de resultados, que a veces funcionan y otras no.

El resultado de cubrimiento de código se puede ver en /var/coverage.

🎯 Implementación de una API REST con el framework Symfony para la gestión de usuarios y resultados.

Esta aplicación implementa una interfaz de programación REST desarrollada como ejemplo de utilización del framework Symfony. La aplicación proporciona las operaciones habituales para la gestión de entidades (usuarios y resultados). Este proyecto utiliza varios componentes del framework Symfony, JWT (JSON Web Tokens), el logger Monolog y el ORM Doctrine.

Para hacer más sencilla la gestión de los datos se ha utilizado el ORM Doctrine. Doctrine 2 es un Object-Relational Mapper que proporciona persistencia transparente para objetos PHP. Utiliza el patrón Data Mapper con el objetivo de obtener un desacoplamiento completo entre la lógica de negocio y la persistencia de los datos en los sistemas de gestión de bases de datos.

Por otra parte se incluye parcialmente la especificación de la API (OpenAPI 3.0) . Esta especificación se ha elaborado empleando el editor Swagger. Adicionalmente se incluye la interfaz de usuario (SwaggerUI) de esta fenomenal herramienta que permite realizar pruebas interactivas de manera completa y elegante.

El primer paso consiste en generar un esquema de base de datos vacío y un usuario/contraseña
con privilegios completos sobre dicho esquema.

A continuación se deberá crear una copia del fichero ./.env y renombrarla como ./.env.local. Después se debe editar dicho fichero y modificar la variable DATABASE_URL con los siguientes parámetros:

• Nombre y contraseña del usuario generado anteriormente
• Nombre del esquema de bases de datos

Una vez editado el anterior fichero y desde el directorio raíz del proyecto se deben ejecutar los comandos:

$ composer update
$ php bin/console doctrine:schema:update --dump-sql --force

El proyecto base entregado incluye el componente lexik/jwt-authentication-bundle para la generación de los tókens JWT. Siguiendo las instrucciones indicadas en la documentación de dicho componente se deberán generar las claves SSH necesarias con los comandos:

$ mkdir -p config/secrets/jwt
$ openssl genpkey -out config/secrets/jwt/private.pem -aes256 -algorithm rsa -pkeyopt rsa_keygen_bits:4096
$ openssl pkey -in config/secrets/jwt/private.pem -out config/secrets/jwt/public.pem -pubout

En la instalación de XAMPP el programa openssl se encuentra en el directorio XAMPP/apache/bin. El resto de la configuración ya se ha realizado en este proyecto. Como pass phrase se empleará la especificada en la variable JWT_PASSPHRASE en el fichero .env.

Para lanzar el servidor con la aplicación en desarrollo, desde la raíz del proyecto se debe ejecutar el comando:

$ symfony serve [-d]

Antes de probar la interfaz de la API es recomendable crear al menos un usuario con permisos de administrador. Para conseguir este objetivo se ha proporcionado un comando disponible a través de la consola de Symfony. La descripción del funcionamiento de este comando puede obtenerse con:

$ php bin/console miw:create-user --help

A continuación ya se puede realizar una petición con el navegador a la dirección https://127.0.0.1:8000/

El contenido y estructura del proyecto es:

• Directorio raíz del proyecto .:
  • .env: variables de entorno locales por defecto
  • phpunit.xml.dist configuración por defecto de la suite de pruebas
  • README.md: este fichero
• Directorio bin:
  • Ejecutables (console y phpunit)
• Directorio src:
  • Contiene el código fuente de la aplicación
  • Subdirectorio src/Entity: entidades PHP (incluyen anotaciones de mapeo del ORM)
• Directorio var:
  • Ficheros de log y caché (diferenciando entornos).
• Directorio public:
  • index.php es el controlador frontal de la aplicación. Inicializa y lanza el núcleo de la aplicación.
  • Subdirectorio api-docs: cliente Swagger y especificación de la API.
• Directorio vendor:
  • Componentes desarrollados por terceros (Symfony, Doctrine, JWT, Monolog, Dotenv, etc.)
• Directorio tests:
  • Conjunto de scripts para la ejecución de test con PHPUnit.

La aplicación incorpora un conjunto de herramientas para la ejecución de pruebas unitarias y de integración con PHPUnit. Empleando este conjunto de herramientas es posible comprobar de manera automática el correcto funcionamiento de la API completa sin la necesidad de herramientas adicionales.

Para configurar el entorno de pruebas se debe crear un nuevo esquema de bases de datos vacío, y una copia del fichero ./phpunit.xml.dist y renombrarla como ./phpunit.xml. De igual forma se deberá crear una copia del fichero ./.env.test y renombrarla como ./.env.test.local. Después se debe editar este último fichero para asignar los siguientes parámetros:

• Configuración del acceso a la nueva base de datos (variable DATABASE_URL)
• E-mail y contraseña de los usuarios que se van a emplear para realizar las pruebas (no es necesario insertarlos, lo hace automáticamente el método setUpBeforeClass() de la clase BaseTestCase)

Para lanzar la suite de pruebas completa se debe ejecutar:

$ ./bin/phpunit [--testdox] [--coverage-text]

Adicionalmente, para comprobar la calidad de las pruebas, el proyecto incluye test de mutaciones generados con la herramienta Infection. El funcionamiento es simple: se generan pequeños cambios en el código original (mutantes), y a continuación se ejecuta la batería de pruebas. Si las pruebas fallan, indica que han sido capaces de detectar la modificación del código, y el mutante es eliminado. Si pasa las pruebas, el mutante sobrevive y la fiabilidad de la prueba queda cuestionada.

Para lanzar los test de mutaciones se ejecutará:

> composer infection

Por último, también se han añadido dos herramientas para el análisis estático de código, PHPStan y PhpMetrics. PhpStan es una herramienta de análisis estático de código, mientras que PhpMetrics analiza el código y permite generar informes con diferentes métricas de proyecto. Estas herramientas pueden ejecutarse a través de los comandos:

> composer phpstan
> composer metrics