Automated tests will make it far easier to gauge if we've introduced a regression or otherwise broke something, as well as can help verify that our behavior is correct.
These tests can run headless (as per #103), or still render (in which we'd see the effects on screen.)
As such, it is technically not reliant upon #103.
The tests should override the normal "load a map upon page load and begin" logic.
Instead tests will instruct the game engine when to load maps or perform actions.
This will be done via a dedicated testing API.
Care should be taken here if tests need a fresh game state between tests, since that would require special "reset" logic which may be buggy itself.
It should probably just take care to reset config, globals, construct a new GameMap instance, a new Player instance, etc.
The other method would be to in fact force a full page reload, such as by using page anchors (# fragments) to demarcate test numbers. For example:
// End of test 1, move to test 2
location.href = '#test=2'
Otherwise we could either use the query string (support conjunctions -- ?foo=bar&bar=baz) or store the current running test in localStorage.
API
The API will require some adapters which promise-ify engine functions, since the engine primarily uses callbacks at this point (pursuant to #24 this should be rectified in the future).
This will allow us to use seemingly straight-line imperative code to write our tests.
Let's show a hypothetical example:
async function testPlayerMovesAfterWalking() {
await loadMap("artemple"); // Wait for the artemple map to load
await walk(player, {x: 96, y: 103}); // Wait for the player to complete walking
deq(player.position, {x: 96, y: 103}); // Deep-assert that the player's position is at the target.
}
As you can see, we hide away concurrencies using promises and async/await, to wait for concurrent actions to be completed.
In this test, if the player had stopped walking on a tile not the original target, the assertion -- and transitively, the test -- would fail.
Automated tests will make it far easier to gauge if we've introduced a regression or otherwise broke something, as well as can help verify that our behavior is correct.
These tests can run headless (as per #103), or still render (in which we'd see the effects on screen.) As such, it is technically not reliant upon #103.
The tests should override the normal "load a map upon page load and begin" logic. Instead tests will instruct the game engine when to load maps or perform actions.
This will be done via a dedicated testing API.
Care should be taken here if tests need a fresh game state between tests, since that would require special "reset" logic which may be buggy itself.
It should probably just take care to reset config, globals, construct a new
GameMap
instance, a newPlayer
instance, etc.The other method would be to in fact force a full page reload, such as by using page anchors (
#
fragments) to demarcate test numbers. For example:Otherwise we could either use the query string (support conjunctions --
?foo=bar&bar=baz
) or store the current running test inlocalStorage
.API
The API will require some adapters which promise-ify engine functions, since the engine primarily uses callbacks at this point (pursuant to #24 this should be rectified in the future).
This will allow us to use seemingly straight-line imperative code to write our tests.
Let's show a hypothetical example:
As you can see, we hide away concurrencies using promises and async/await, to wait for concurrent actions to be completed.
In this test, if the player had stopped walking on a tile not the original target, the assertion -- and transitively, the test -- would fail.