Actividad 4 - Grupo 11

[franlucich]

https://github.com/pchesini/vetsoft

[ivanduva]

Buenas! Les puedo pedir el link a donde lo deployaron?

[franlucich]

Buenas, acá está: https://vetsoft-y9ni.onrender.com/

[ivanduva]

Buenas,
Les pedimos algunas correcciones:

• El form de editar no muestra las validaciones en los inputs, sino que directamente no guarda cuando hay errores y vuelve atrás. Debería mostrar los mensajes de error como al crear el cliente.
• No aparece el mensaje de error en el input del nombre. Al arreglar esto, agreguen un test e2e.
• En cuanto a la validación de que el teléfono empiece con 54, el test e2e no es relevante. El assert está hecho para probar que lo que ustedes mismos escribieron manualmente unas líneas antes, efectivamente contenga 54. Lo que debería hacer es chequear que en el caso de ingresar un número sin 54, aparezca el error correspondiente.
• En cuanto a la validación del email, se permite agregar "@vetsoft.com" sin nada adelante. Arreglen eso y el test de unidad, ya que prueba que no se cree el cliente en lugar de que aparezca el error. Probar que no se cree el cliente no es del todo correcto porque no es específico. La creación puede estar fallando por muchas razones.
• En cuanto a la validación de que el teléfono sea numérico, agreguen un test e2e y uno de unidad
• Luego de hacer todo, saquen una release.

Recuerden que los cambios deben ser realizados por las personas que se encargaron de cada issue.

Después les dejamos algunos comentarios sobre procedimiento que deberían revisar en las próximas correcciones:

• Vimos que hicieron commits sobre main para agregar lo relativo a la CI/CD. Si estamos usando el workflow Feature Branch, esto es peligroso y constituye una muy mala práctica. Estos commits no pasan por una instancia formal de review y por lo tanto es poco seguro, puede romper la aplicación. Hay que hacer PRs para cumplir con el proceso.
• Vimos que en al menos un caso, alguien se metió en un PR que realizó otra persona e hizo algunos merges. Luego avisó con un comentario. Ese comportamiento es un poco extraño, sobre todo porque en una review la idea es que haya un buen feedback para que les sirva a todas las partes. En lugar de eso, se le podría haber hecho un comentario informando el problema y la posible solución para que la persona encargada del PR pueda revisar lo que hizo y arreglarlo.
• Vemos algunos malos mensajes de commits. Por ejemplo: pchesini/vetsoft@97f3049. Recuerden que el mensaje de commit debería ser una síntesis de la funcionalidad que ese commit resuelve. En ese caso por ejemplo un buen mensaje sería "Elimino import innecesario".

Por otro lado, hay algunos puntos en donde vemos un buen trabajo. Hay algunas buenas reviews y la documentación de los PR está buena también. En ese sentido sigan así.

Arreglando eso ya tendrían el trabajo integrador completamente aprobado.

La última fecha límite de será el último día de cursada antes de las vacaciones: Lunes 8 de Julio 23:59 hs.

Saludos

[franlucich]

Hola profe, ahi ya realizamos las correcciones. Saludos!

[ivanduva]

Buenas chicos,
Perfecto, el trabajo integrador queda aprobado.
Felicitaciones!

Saludos