2 May 2017Twine 2.1.3

This originally appeared on my Patreon.

This fixes a bad bug with 2.1.2 that could cause stories to become corrupted, so if you have downloaded 2.1.2, please upgrade to this as soon as you can.

This seems like a reasonable time to talk about how testing with Twine works. Initially, the test suite used a tool called Selenium that scripted actions in a web browser and verified the results. The problem with this approach is that it has turned out to be both brittle and flaky. Brittle because I would make a change to a small part of the code and 5 tests would break sometimes, and flaky because there were often difficult-to-debug timing issues with the tests that would cause them to succeed some of the time, and not others -- on the same code. Not ideal.

(I know there are lots of happy users of Selenium, to which I say: good on you. But it hasn't been good to me.)

With the Twine 2.1 series, I've been focusing on unit testing, which isolates each part of the code and tests each bit of it individually. It's been a lot more reliable thus far, but it takes time to write all the tests. I've been focusing unit tests on the data layer, because bugs that cause data corruption are the worst in the world. They trash users' work and leave me feeling horribly guilty. I'm the dog that ate your homework.

The bug that was in 2.1.2 didn't have any testing associated with it. It was a sin of omission: if a grid spacing wasn't specified when snapping passages to the grid, passages that are automatically created as you edit your story (e.g. when you type [[A link]]) would be assigned nonsense coordinates onscreen (NaN, if you speak JavaScript), which firstly caused them to not be displayed, and secondly could cause other passages to get their coordinates trashed, as Twine tries to keep passages from overlapping each other.

(No, there isn't any way for an end user to change grid spacing, because it's always felt unnecessary to me... but it's always good to leave ourselves that option should we want it someday.)

Now the offending code has checks for grid spacing, and there is a specific test to check that it handles those situations correctly. So it shouldn't happen again. Let's hope. There is always a degree of uncertainty with software engineering.