Actividad 4 - Grupo 4

[MatyRusso22]

https://github.com/MatyRusso22/vetsoft

[ivanduva]

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

[MatyRusso22]

Buenas profe, me surgio una consulta.

Al momento de hacer una correccion, tenemos que crear una version nueva con el formato x.x.1, indicando de que se arreglo un bug? o simplemente no hacemos una nueva release y solo arreglamos el error?

[ivanduva]

En este caso, les pedimos que saquen una release luego de hacer todas las correcciones. El número de versión está bien, en la release habría que cambiar el último número porque son bugs.

[MatyRusso22]

Buenas profe, ya corregimos los bugs que nos menciono.

Tambien le queria comentar que tuve un bug con mi carpeta local de git, y por este termine pusheando al repositorio de manera no intencionada. Lo solucione realizando una nueva rama para hacer un revert, y luego haciendo un pr para mergear ese revert asi volvia al estado antes de mi error. En ese pr entro mas en detalle sobre el tema (MatyRusso22/vetsoft#36)

Saludos! Equipo 4 (Sivori, Daza, Ruival, Baroni, Russo)

[ivanduva]

Buenas,

• No vemos la corrección que les pedimos sobre los tests de unidad e integración sobre el email. Serían test_update_client_with_error_wrong_email_not_end_vetsoft y test_edit_user_with_invalid_data_test_email_not_end_vetsoft respectivamente.
• En cuanto a los tests de unidad e integración del campo ciudad, son irrelevantes porque el arreglo que hicieron es sobre el form. Los tests de unidad e integración no testean la interfaz. Además no les pedimos que agreguen otros tests sino que modifiquen los que habían agregado antes (test_update_client_with_error_wrong_city y test_edit_user_with_invalid_data_test_city). Lo que deberían hacer esos tests es testear que la función de validación del modelo devuelva el error correspondiente cuando la ciudad no es correcta (unidad) y que la API devuelva el error correspondiente cuando la ciudad no es correcta (integración).

Ambos casos son parte de lo mismo. Como dijimos antes, están probando que el cliente no se modifique en caso de datos erróneos. Lo cual no es específico ya que el hecho de que no se modifique puede pasar por muchas razones y el test no estaría atajando el error correspondiente. Por eso les pedimos que testeen que salte el error en específico en cada caso.

Otra cuestión menor que vimos es que el número de versión que usaron en este caso no es del todo correcto. Cuando se solucionan bugs sin agregar features, en general se cambia el último número. Para saber más pueden revisar este link que también está en la documentación de la actividad: https://semver.org/lang/es/.

Después de solucionar los problemas, saquen una nueva release. Y recuerden como siempre que cada cosa deberá resolverla el encargado de cada issue.

Saludos

[MatyRusso22]

Buenas profe, ahi corregimos lo que nos pidió, e hicimos una nueva release 1.7.1. Saludos!

[ivanduva]

Perfecto, queda aprobado el trabajo integrador.

Saludos