Amigar los tests y Wollok Game

[PalumboN]

Este año hicimos más énfasis en testear los juegos que producen les estudiantes, y encontramos las siguientes complicaciones:

• El game no se "reinicia" entre cada test y mantiene el estado anterior 👎
• Algunas acciones rompen cuando el juego no está corriendo: game.stop(), sound.play() (y no sé si se me escapa otra).
• game.start() levanta un juego y tilda los tests.

Una propuesta es hacerle un clear() antes de correr cada test (lo que hicimos este cuatri desde el fixture), que soluciona el primer problema pero no el resto.

Quizá valga la pena pensar en una especie de mocking y que estos objetos tengan otro comportamiento en los tests. (De hecho algo así ya se puede hacer a mano, pero hay que parametrizar todas los usos de game y es una paja, por eso buscaba algo más automágico).
Algo un poco relacionado con esto último se encuentra acá: #1755

[asanzo]

De acuerdo. Me imaginaba un

fixture {
     game.prepareForATest()
     ....
}

Y manejamos los mocks por adentro, haciendo que el start() no haga nada (o que corra en otro hilo, o whatever), que no reproduzca los sonidos, y todo lo que encontremos que rompe los tests.

[PalumboN]

Yo esperaba Wollok se de cuenta que está corriendo un test y ese prepareForATest() se haga solo.

[asanzo]

[ezequielPereyra]

Dejo un comentario con respecto a wollok-ts probado con Cooking Ralf a partir de este PR:

• Si sacamos esta validación pareciera que no hace falta mockear los sonidos (o un proveedor de sonidos) porque los tests corren bien.
• En Xtext si no metemos un game.clear() en el initialize() de los tests, los mismos pueden romper porque se guarda el estado de game entre tests. Pero en wollok-ts esto pareciera no suceder. Sin hacer el clear los tests pasan bien, cosa que en Xtext no pasa.

@PalumboN Con esto nuestra vida es más feliz (?

¡Saludos!

[PalumboN]

@ezequielPereyra uqbar-project/wollok-ts#95