Testeo del sistema de control de votos anónimos

Los malandriners desatados no descansan. Han demostrado ser maestros en el arte de burlar cualquier restricción que les pongamos. Pero esta vez no nos pillarán desprevenidos.

Necesitamos un arsenal de tests automatizados que pongan a prueba nuestro sistema de control de votos anónimos y garanticen que las medidas implementadas son efectivas. Si fallamos aquí, los malandriners arrasarán con todo.

Historias de usuario:

Como administrador, quiero verificar automáticamente que las restricciones de voto anónimo funcionan, para mantener la integridad del sistema de votación frente a intentos de manipulación.
Como desarrollador, quiero detectar fallos en el sistema de votación a través de tests automatizados, para prevenir ataques de los malandriners antes de que ocurran en producción.

Tarea A - Los tests

Nota: Esta tarea tendría su propia PR

Tres tipos de tests (En Laravel y en cualquier software)

Unit: Unitarios — Lógica aislada.
Feature: Integración — Flujo completo en el backend.
Browser/Dusk: End-to-end — Simulación en navegador (experiencia del usuario).

Puedes ver un ejemplo de cada en esta PR

Nos centraremos en los últimos: Test end2end:

Usando Laravel Dusk, simular usuarios anónimos que intentan votar desde:

El mismo navegador con diferentes cookies.
Distintas sesiones en el mismo dispositivo.
Diferentes dispositivos emulados.

Tarea B - Justificación para que existan los test

Nota: Esta tarea tendría su propia PR

Hemos detectado de la tarea anterior que hay cierto código que se puede refactorizar dentro del VoteController.

Lo podemos ver siempre cuando aparece código repetido.

Existen 2 opciones

Opción A

Utilizar un solo sistema de validación que agrupe los 3 que se han añadido.

Los tres son consultas sobre la base de datos.

Opción B

Es la que elegiremos.

Dar un salto a pro y buscar una forma de consolidar un sistema que sea escalable y fácilmente testeable.

Hemos visto como cada Service tiene un método de comprobación. Todos se parecen bastante.

Gracias a eso podemos entender que se podría tener un contrato para que nuestros Services tuvieran la misma firma y pudieran intercambiarse.

De esta forma podríamos crear un Validator que permitiera usar tantos validadores de voto como quisiéramos y que pudieran ordenarse al gusto.

Todos independientes, pero todos cumpliendo el contrato.

Buscamos que primero crees los tests antes de refactorizar. Una vez refactorizado los tests deben aparecer en verde porque todo funciona correctamente.

Criterios de aceptación

Tarea A - Los tests

[ ] Los tests end-to-end con Laravel Dusk simulan:
- [ ] Intentos de voto desde el mismo navegador con diferentes cookies.
- [ ] Intentos de voto desde distintas sesiones en el mismo dispositivo.
- [ ] Intentos de voto desde diferentes dispositivos emulados.

Tarea B - Justificación para que existan los tests y refactorización

[ ] El código del VoteController se analiza para identificar repeticiones o patrones que puedan refactorizarse.
[ ] Se implementa una interfaz (Interface) para consolidar los métodos de validación de los servicios existentes.
[ ] Se crea un sistema de validación escalable que permita añadir nuevos validadores sin modificar la lógica existente.
[ ] Todos los tests escritos previamente pasan correctamente tras el refactor.

webreactiva-devs / calambrazo-silver-oslo