Tanto aquí como en zona.go podrías llevar los errores a un archivo a parte para usar mejores prácticas

Es cierto, pero por sencillez y mayor interacción con la terminal en la ejecución de los tests, opté por hacer un simple print en el shell. En un futuro seguramente lo cambie a un archivo.

Tampoco soy un experto en GO pero si ya atrapas los errores en las clases correspondientes de cada objeto, ¿por qué vuelves a poner un mensaje en el código con el que testeas?

No es ser experto en GO, es un concepto básico que había entendido mal sobre los tests del objetivo. Ahora los he corregido para que sean los correctos (aunque aparezcan menos) pero con más sentido.

genial entonces!

En la documentación has dicho que has elegido la biblioteca testing, pero no has justificado la elección de esta. ¿Por qué has usado testing y no otra? ¿Qué requisitos tiene tu proyecto para haberla elegido?

Listo, documentado aquí

¿Devolver nil está bien? ¿No se podría comprobar si se alza un error en lugar del valor devuelto?

Realmente se devuelven dos valores, pero se comprueba el segundo en el caso de errores (se deshecha el primero haciendo uso de la variable _).

Respecto a nil, es el convenio de go para tratar los errores. Somos nosotros los que debemos asegurarnos de que si pasa "lo que no quieres que pase" se devuelva ese valor, que no es más que un valor indeterminado para punteros, funciones interfaces, mapas y slices.

Entiendo que te refieres a capturar los errores como se haría por ejemplo en Java, con un bloque try/catch, pero lametablemente eso no existe en Golang. Este lenguaje se caracteriza por tener errores estrictos que terminan el programa o funciones que permiten evitar el tratamiento de errores.

Te pongo un ejemplo:

Los desarrolladores de golang se suelen quejar de que las personas suelen hacer sentencias try/catch realmente extensas, que no siguen buenas prácticas de código limpio y sencillo. Por lo que esta función (que da error en tiempo de compilación si el fichero no existe)

f := os.Open("filename.txt")

Se trataría de la siguiente forma:

f, _ := os.Open("filename.txt")

Otro ejemplo que motiva este paradigma:

Imagina que en Java abres un fichero y empiezas a escribir en él, y llegado a un punto debes cerrar el fichero (debes cerrar el stream), por lo que deberías buscar en un posible try/catch extenso las opciones que deberías limpiar antes de cerrar.
En golang por ejemplo se usa la función defer(), que abre un fichero y simplemente lo cierra cuando ejecutas una función que deseas, por lo que te permite olvidar de los errores comunes por no cerrar un fichero, de que el fichero no exista, de que se te haya olvidado limpiar alguna opción, etc.

No lo sabía, me parece supercurioso. Lo has explicado muy bien, me ha quedado clarísimo. Muchísimas gracias!

Muchas gracias a ti también!!

PD: Tu avatar mola mucho

Deberías justificar por qué utilizas la biblioteca testing. Está muy bien utilizada siguiendo estándares y tal pero ¿por qué esa biblioteca y no otra?

Listo, documentado en el fichero corresopndiente.

Me gusta la forma en la que gestionas los posibles errores dentro de las propias clases y también dentro de los tests, pero quizá deberías añadir test que comprueben el correcto funcionamiento, no sólo la buena gestión de errores. Por ejemplo, yo hice test que creaban objetos y se aseguraban (con assert) de que en efecto los campos importantes no estaban vacíos y el objeto estaba bien creado. Aún así me gustan tus test gestionando los errores, solo es una sugerencia para añadir otros tests.

Entiendo tu punto de vista, y ciertamente lo comparto, pero es cierto que siguiendo el principio F.I.R.S.T. y haciendo los tests lo más sencillos y rápidos posibles, el uso de la función assert añadiría carga extra en algo que podemos considerar obvio, pues lo hace el compilador. Si introducimos un número como título de una actividad (que debe ser string), el propio compilador nos dará error para ello.

Es cierto que podría diseñar un test con la función assert que compruebe que efectivamente la zona que se ha proporcionado para la creación del objeto actividad es correcta. Esta función no está contemplada en el entorno normal de go, para su uso se debería añadir una biblioteca como testify, o crear una función assert propia.

Sigo pensando que deberías comprobar el buen funcionamiento de alguna forma, pero entiendo tu punto de vista de querer hacer rápidos los tests.

Hazle caso a @JAntonioVR . Realmente sólo estás testeando que se crean correctamente, no hay ninguna funcionalidad que estés testeando.

Muy buena gestión de errores, pero yo tendría en cuenta la posibilidad de que la zona que llega en el constructor sea nil. Aunque por otra parte si termina de construirse es porque no peta el constructor de Zona (yo es que soy muy de dobles comprobaciones, pero es sólo una sugerencia).

Es cierto que se podría hacer, pero sería añadir código innecesario (además de que no es posible hacer lo que pides en este lenguaje de programación).

Surgen los siguientes problemas:

• nil es un valor indeterminado que se usa solo para punteros, interfaces, mapas, slices, canales y funciones. En este caso se usa en la interfaz error, pero no podría hacer lo mismo para el objeto de tipo Zona (salvo que lo enviase a la función como un puntero, cosa que no debería por el siguiente motivo).
• El mero hecho de que el puntero sea indeterminado no aporta nada a la creación del objeto, puesto que si ha pasado por el constructor de Zona y ha sido validado (ha pasado los tests) es que se debe haber creado correctamente. Es lo que comentabas anteriormente de la doble comprobación.

Cuestiones del lenguaje entonces, si es inviable o dificulta el desarrollo de los test solo queda confiar en el objeto de tipo Zona y en que no vaya a tomar valores incorrectos (y para eso están sus propios tests)

Como dicen mis compañeros, deberías de justificar por qué utilizas la biblioteca testing en algún lugar de la documentación. En cualquier justificación técnica siempre es necesario que establezcas unos requisitos antes de nada, realices una búsqueda parametrizada de los mismos y finalmente elijas aquel que mejor los cumpla.

Listo, justificado en el archivo correspondiente.

Revisando la documentación de Go, veo que has seguido las mejores prácticas para la realización de tests, por esta parte 💯 .

Muy buena justificación, pero deberías hacer la comparación de alternativas antes de comunicar la decisión final

Listo, es verdad, es mejor cambiar la estructura para que quede antes la comparativa que la decisión final

Me temo que es el código de la lógica de negocio lo que tienes que desarrollar. Tampoco un chat es realmente lógica de negocio. Repasa el concepto, por favor.

El chat era un vestigio de un anterior objetivo que se me pasó quitar, lo comentamos en clase un día y decidí quitarlo.

Hazle caso a @JAntonioVR . Realmente sólo estás testeando que se crean correctamente, no hay ninguna funcionalidad que estés testeando.