Opciones para escribir tests para Fleet Management

[unjust]

Queremos probar integration tests de Fleet Management que idealmente son agnostica de lenguaje. Este puede ser mucho de pedit, pero vamos probando algunas ideas:

• probando con Postman y verificando si puede ser algunos tests minimo en el free tier
• pensamos que no seria mal crear tests en JS que puede interactuar con el API en cualquier lenguaje, al menos las estudiantes estan familiarizado con javascript, el punto de los tests son para probar la comportamiento de su API, no desarrollar los tests
• usamos playwright para pruebas https://playwright.dev/docs/api-testing https://github.com/Laboratoria/impl-fleet-management-api-py-flask/pull/20

[unjust]

Hice una prueba con playwright en el repo de fleet management
Necesitamos ser clara que estes tests no reemplaza la necesidad su propio unit y integracion tests, es solo una herramienta confirmar si tu API cumple criterios. Con GET no necesitamos mockear un base de datos, pero hay que pensarlo cuando hacemos pruebas de POST o DELETE.
Cuando tengamos estos tests clara hay que definir mejor las rutas de endpoints y nombres de parametros en el readme.

Pros:

• muy facil
• podemos correrlo en un workflow para ellas sabes de una vista si va bien o no

Cons:

• quiza tener un package json en su proyecto que puede ser confuso?

---

Update: Decidmos usar Postman para tener un solocion que no agrega codigo al proyetco y tambien ayuda que ellas aprenden esta herramienta

[unjust]

Creo estas pruebas son para confirmar que su API conforme a los criterios, similar a los tests en BQ API (que tambien vamos a renovar). Por ejemplo, que devuelva data en una estructura array y con un status particular, obedece las parametros de paginacion y otros. Por eso debemos definir mejor que sus rutas estan definidos en algun manera y no deja abierto - por ejemplo /taxis /locations/[taxt_id]etc.
Creo aun ellas pueden escribir unit tests, y tambien puede escribir tests de integracion en su propio framework (como con el Flask client o en Django) , quiza hay casos que no son cubiertos con los tests que entregamos. Creo lo que vamos entregar con el proyecto son solo para darnos y ellas un señal / respuesta rapida si van bien con su API o no, pero no reemplaza todo el testing.

[cros410]

He realizado una prueba de concepto que responde al punto:

• Probando con Postman y verificando si puede ser algunos tests minimo en el free tier

La implementación y PR se encuentra aquí

@unjust creo que esto puede validar lo que hemos conversado y atacar las pruebas e2e de forma agnóstica al lenguaje de implementación y dejar las unitarias y de integridad de datos a cada lenguaje con su framework correspondiente.
Para ponernos de acuerdo con las estructuras de consulta y respuesta podemos usar la documentación que compartió @ssinuco de todas maneras se puede convertir la documentación armada en Postman a Swagger con esta herramienta web

[cros410]

Teniendo como base esta documentación creo que hay algo que tenemos que terminar ponernos de acuerdo:

1. Puerto compartido para todas las estudiantes -> Sugerencia el 8080
2. Documentación del api. Según hemos venido conversando nos vamos a guiar de la siguiente documentación. Aquí tengo unas sugerencias

• Podemos ponerle el prefijo de /auth para que esté bajo un contexto
  
• Solo dejar esta ruta con los parámetros de page y limit
  
• Cambiar para que tanto el taxiId, date, page y limit se envíen por query para respetar la jerarquía en la URL. Adicionalmente haría la aclaración del formato de la fecha algo como DD-MM-YYYY
  
• Mismos comentarios que el punto anterior
  
• Nos tenemos que poner de acuerdo sobre las estructuras de respuesta en todos los endpoints. Creo que solo hay una diferencia entre la respuesta de la historia 3 y 4. Sugiero que nos quedemos con la de la historía número 4 donde la placa se incluye dentro del contenido
  
  

Con estos cambios creo que podemos armar bien el contenido de las pruebas de postman.
@unjust
@ssinuco
Compartir esto de igual manera con los responsables de los otros lenguajes para poder avanzar con esto

[unjust]

@cros410 estoy de acuerdo con casi todos los cambios (formato de fecha, consistencia de data en HU3 y HU$, omitir query como parametro)

Para mi trajectories/{{taxiId}} creo semanticamente tiene sentido ponerlo en el url y me gusta que tienen experiencia con paramteros en el url y no solo search params. Podemos definir also como por defecto devuelva los trajectories de ultima dia o misma dia (pues la data es bien viejo enctonces no devuelva nada si es mismo dia). Pero estoy flexible en este idea si pensamos mejor dejarlo como query param.

Y no se si GET taxis y GET trajectories debe necesitar admin o solo un header con token suficiente. Los operaciones de post patch delete de users si.

[davidgranados]

@unjust @cros410 creo que trajectories/{{taxiId}} no tiene mucho sentido... si en el path param va el taxi id, no debería ser taxis/{{taxiId}}/trajectories ? si trajectories es el recurso principal me parece que entonces si deberai ser /trajectories?taxiId={{taxiId}}

[unjust]

Ok entiendo @davidgranados. Veo los query params mas como filtros opcionales por eso tambien pensaba que tiene mas sentido como parte de path.
Me gusta la idea de taxis/{{taxiId}}/trajectories porque no veo otro oportunidad usar path parameters en el proyecto. Pero quiza eso no es tan importante.

Si quedamos con trajectories/, me pregunto si el endpoint trajectories/ sin query params debe retornar algo, no?
Ahora en la historia de usuario creo taxiId y date son requeridos y no definimos que trajectories/ retorna algo sin ellos. Me parece un poco rara.

[cros410]

@unjust dentro del contexto de usuario si hay oportunidad de usar path parameters

Estoy de acuerdo con @davidgranados sobre las dos opciones que tenemos para la HU3

a) /taxis/{{taxiId}}/trajectories?date=02-02-2008
b) /trajectories?taxiId={{taxiId}}&date=02-02-2008

Hasta el momento cuando me a tocado guiar a estudiantes he optado por la (b). Según los GIF que a sumado @ssinuco cobra más sentido la (a) porque no hay caso de uso para solo listar toas las trayectorias sino que siempre se necesitan en base a un taxi en especifico.
Lo que si recomendaría como comenta @unjust es mencionar que todos los parámetros por query son opcionales y de no enviar algunos tener valores con defecto como el pageSize y pageNumber y otro no como el date y posiblemente el taxiId