Skip to content
This repository has been archived by the owner on Nov 3, 2020. It is now read-only.

Support automated testing #104

Open
darkf opened this issue Nov 28, 2017 · 0 comments
Open

Support automated testing #104

darkf opened this issue Nov 28, 2017 · 0 comments

Comments

@darkf
Copy link
Owner

darkf commented Nov 28, 2017

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.

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Projects
None yet
Development

No branches or pull requests

1 participant