Fix #182 failing tests

[fdodino]

Resumen, ver #182

• para los tests de fullRepl, evitamos abrir un socket para conectarnos al diagrama dinámico (puerto 3000), porque los tests no lo consideran
• lo mismo para los tests que prueban solo la interacción con el diagrama generado ahora por wollok-web-tools (diagram.test.ts)
• en el caso de dynamicDiagram.test.ts que sí prueba toda la interacción del repl con el socket del diagrama dinámico, agregamos un finally para que cierre el server al final, ya que si tiraba error el server.close() no se ejecutaba y los otros tests que dependían de tener el puerto 3000 libre fallaban
• el más difícil de todos fue el run.test.ts, ya que el test del game confiaba en chai, a partir de recibir una función done como parámetro. No obstante, necesitamos cerrar el ioGame. Al principio fui por la propuesta de agregar un parámetro dryRun en las opciones del run, pero después se me ocurrió devolver el ioGame en la promesa. Con eso el test pudo poner un await, cerrar el ioGame a mano y luego testear que el juego anduvo correctamente. En caso de error logueamos el mensaje para tener una buena experiencia de desarrolladore. Para testear game creé un ejemplo más, y de paso adelanté la validación de la carpeta assets que estaba metida dentro del método eventFor.

La duda que me queda es acá:

  const currentHost = gameHost(host!)
  const currentPort = gamePort(port!)
  server.listen(parseInt(currentPort), currentHost)  // listen 1

  logger.info(successDescription('Game available at: ' + bold(`http://${currentHost}:${currentPort}`)))
  server.listen(currentPort)  // listen 2

¿está bien tener un doble listen?

[PalumboN]

GROSO Dodain!!! 👨‍💻 🥇 👾

de paso adelanté la validación de la carpeta assets que estaba metida dentro del método eventFor

Entiendo que esto cambió el comportamiento: antes fallaba cuando se conectaba el server y al levantar la consola, no?
Recuerdo de haber peleado con Ivo por eso, habría que hacer una buena prueba si eso falló.

---

¿está bien tener un doble listen?

No vi dónde está eso... no suena bien, pero si no se queja y funciona como queremos 🤷

[PalumboN]

Yo en un momento que vimos este error pensé en algo así, pero no me gustaba principalmente porque quiero que ese io se levante desde una native de game (y que a la consola le de lo mismo que sea desde un program, game o REPL).

Pero podemos dejarlo así y después hacer el cambio (para mí sería mejor que devolviera el interpreter, y buscar el io en el objeto game) 😉

[fdodino]

me gusta pero no estoy seguro de cómo ese ioGame vive dentro del intérprete. +1 a salir con ésto y mejorarlo más adelante.

[PalumboN]

😮

[fdodino]

Hice la prueba: levanté un juego en el 3000 y corrí los tests y falla correctamente el test de game porque dice que el puerto 3000 está en uso. Pero no tiene mayores problemas, los otros tests pasan. Cerré el juego, volví a correr los tests y pasaron perfectamente. Así que me animé a eliminar esos comentarios tremendistas.

[fdodino]

GROSO Dodain!!! 👨‍💻 🥇 👾

de paso adelanté la validación de la carpeta assets que estaba metida dentro del método eventFor

Entiendo que esto cambió el comportamiento: antes fallaba cuando se conectaba el server y al levantar la consola, no? Recuerdo de haber peleado con Ivo por eso, habría que hacer una buena prueba si eso falló.

A mí me parecía un feature, pero podemos volverlo para atrás si quieren dejar corriendo el juego aunque sea con las imágenes rotas. De paso probamos el test para comprobar que falle.

¿está bien tener un doble listen?

No vi dónde está eso... no suena bien, pero si no se queja y funciona como queremos 🤷

server.listen(parseInt(currentPort), currentHost)

El doble listen está en la función initializeGameClient. Para mí está bueno revisar y confirmar que solo hagamos lo que el motor del juego necesita (podría pasar que el juego esté procesando dos veces las cosas, o podría simplemente no pasar nada, mejor estar seguro)