Open PalumboN opened 4 years ago
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.
Yo esperaba Wollok se de cuenta que está corriendo un test y ese prepareForATest()
se haga solo.
Dejo un comentario con respecto a wollok-ts
probado con Cooking Ralf a partir de este PR:
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!
@ezequielPereyra https://github.com/uqbar-project/wollok-ts/issues/95
Este año hicimos más énfasis en testear los juegos que producen les estudiantes, y encontramos las siguientes complicaciones:
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á: https://github.com/uqbar-project/wollok/issues/1755