I’ve been working on a testing tool called Passage Shell that serves both Twine 2 (Harlowe, SugarCube, and Snowman story formats) and Ink for Web files. It works through an internal web-server that exposes route-based paths that return JSON-encoded objects. It’s the first step in a larger project to study human and bot-based decision making in narrative games through creating a standardized testing API for HTML-based narrative games.
I’m currently looking for feedback, help, or any notes on ways it might be of more use outside of this project for the general community to help with auto- or remote-testing complex projects. (I’ve been pointed at Selenium that other projects have used. I’m hoping to make this tool much simpler to deploy.)
I’m very curious about this (having written a very large and complicated Snowman game with dozens of potential bugs), but I’d like to ask more specific details about what it really does. Is it supposed to play the game on its own? What information does the JSON output contain? Thanks.
Right now, Passage Shell just acts as a middleware of sorts. It serves a file up and allows it to be accessed through different routes. A testing file would then need to be written that starts up this process and then used the routes, going to http://127.0.0.1/text to get the current text of a passage and then http://127.0.0.1/links to get all of the current links in the passage, for example.
The GitHub page speaks a little about this, but each JSON object returned by a route is based on its name. So, like, calling /text might return the following:
{"text:" "Double-click this passage to edit it."}
It doesn’t auto-test anything at the moment. I’m working on another tool to do that.
The hope is to release these small parts of the larger project as they get into a good place for other people in the community to use them to get feedback on how best to revise them.