Transforming a string into a TADS 3 expression?

I’d like to know if anyone thinks it’s possible to transform a string into a TADS 3 expression, or if the unit-testing idea below seems possible in some other way.

Question about transforming a string into a TADS 3 expression
When I say “transform a string into a TADS 3 expression,” I mean, for example, if given the string “!redDoor.isOpen”, does anyone think it would be feasible to create from this an expression that evaluates to either true or nil depending on whether the red door is closed?

Unit-testing idea
The reason I ask the above question is that, if it’s feasible, it could provide a really awesome way of unit-testing games.

What I have in mind is the ability to write an “Assert” meta-verb that could be used for unit-testing as follows:

ASSERT “redDoor.isOpen”
That’s not something you can close. [Bug.]
ASSERT “!redDoor.isOpen”

I’m certain I couldn’t develop this myself. I guess this is a question for whoever out there has written a TADS 3 compiler? Anyone?



Yes, this is perfectly possible, see

But as a side note - text adventure games are quite unique in comparison to traditional computer applications with graphical user interface in one aspect. All user interaction is plain text (typing on keyboard and reading on screen). When I was programming my own game few years ago I’ve used automatized testing heavily, in fact I’ve rarely played the game by myself interactively.

I’ve created really long list of commands to play the game, imagine a walk-through, but much longer doing every imaginable command which occurred to me or which my beta-testers tried out and then made a script which played the game and recorded screen output to a file. Next I’ve executed diff tool to compare actual output of game to last output considered bug free and displayed coloured differences - on one click compile, run test and display differences in game output. Think about it - instead of >ASSERT “redDoor.isOpen” just >x red door. When anything anytime changes you will see it in differences. When you are testing something which can be done five different ways you can use advantage of >undo command. Try one way, undo move and try the same other way and so on. In complex situation you can save position, do something and then load the old position back and continue testing.

Of course there are some rough edges such as random events, but still - with so little work (just few lines of shell scripting and then gradual walk-trough addition) you can get so great coverage of testing, which makes any attempt of unit testing as seen in traditional application development practices quite funny :slight_smile:

Wow, that is awesome. I might just try that. It has been a long time since I looked at dynamic functions, and their value totally bounced off me at the time.

I like your other testing ideas too. Wish I’d thought of them earlier actually.