How often to compile/test?

This originally seemed like an Inform 6/7 question, but I’m curious how often people compile their works.

I recently went two days without meaningfully compiling (beyond saying, oh, look, basic stuff broke) while I was adding a hint system and general details and figured I could play catch-up pretty quickly. I was right. I liked not losing the routine of just typing stuff in. It was a big advantage to be able to stay focused.

And of the code I added, I wrote down tests I needed to go through with anyway–tests that may be better done all at once, instead of switching from testing to programming and back. Or stuff that can be quickly sorted out in Emily Short’s Property Checking or Juhana Leinonen’s Object Response Testing.

But on the other hand, when I have a new feature, or I need to add a puzzle to my game, I obviously need to compile much more frequently and run my standard tests to make sure my change works or find a bug–and document if I need to fix it later. Or at the very least, I want to document with a [??I can’t handle case X right now but I need to sort it out].

Obviously the amount of time compiling/testing is inverse to the complexity, but I’m wondering if there are some simple sensible ways to cut down what I need to compile/test, when, so I can focus on adding fun narrative stuff.

Are there any general guidelines I’ve missed? I’ve googled “how often to compile” and such but wondered if there were anything specific to certain languages here.

Also, are there any safety-nets that can be installed so you don’t need to compile/test as much? Obviously, it’s not a major distraction, but not needing to compile is handy when I get home late and just want to tear through a chunk of my program. I’m just wondering how risky this is, or if other people enjoy being able to set aside time where they just add ideas and don’t hit F5.

I’m not sure if I’m phrasing my question correctly, here, or even if it’s meaningful. But I had a good experience not working with anything technical for a few days, and with lumping relatively simple low-risk tasks together, and I’m curious if other people have found this, too–or the opposite–or if they’ve found it a truism they should work this way.

If I’m adding text to a game, I compile about once per sentence. I cannot get a sense of how a phrase will fit into a sentence, how a sentence will fit into a paragraph, how a paragraph will fit into a room description – without looking at it in context.

If I’m adding mechanics, I compile about once a sentence anyhow – that’s the “oh, look, it broke” level you’re talking about. I don’t go the whole test-driven route; I can write a large chunk of code before I start checking its functionality. But I generally prefer to see the functionality function once it’s there, because otherwise I can wind up down a long road of “Crap, something’s broken in […ten pages of code that I wrote over the past week…].”

That’s a good point. Part of why I asked this question was that when I started, I had a slow computer (Vista) and probably wasn’t compiling enough on I7 to track the technical stuff once my project got big–but at the same time I also like to do all my proofreading at once, because it can be exhausting. Now you mention it, it’s left some holes in my prose where I say “I didn’t mean to say that!” – often baffling my testers. Not sure how much it’s fair to schlep on them, and I suspect I won’t remember all the code-paths touched.

I tend to compile rather often as it acts like a save button, usually after completing a section I’m working on. There’s not much worse than spending hours working on a project only to lose everything due to lack of saving.

Oh, I hit the save button roughly three times per sentence. :slight_smile:

I compile every time my brain stops working, which is a lot. :smiley:

I also wanted to say thanks as I hadn’t come across Emily Short’s Property Checking or Juhana Leinonen’s Object Response Tests before and they’re both going to be really useful for me.

Don’t forget my Simple Unit Tests extention for general purpose testing. :slight_smile:

Glad I could pass that on to someone. I read about them in Aaron Reed’s Inform 7 book. They’re simple to use & cut down my excuses for not implementing something. Sometimes the side points we make wind up being more useful than the main ones :slight_smile:. I encourage others to look at these extensions too–actually, working through implementing everything is probably the lowest-risk way to avoid compiling. Although obviously that’s no assurance things won’t break. But when I need to add stuff without a lot of [if] phrases, or I’m not up for technical stuff, lumping 20 descriptions together is still a good way to get work done.

And yes, I want to get Simple Unit Tests working, too. There’s just so much that’s straightforward and wonderful to work with as is.

Saving isn’t really a problem for me, as I’m used to doing so with non-program writing. I just don’t want to do any heavy compiling some days, so I only do so when I get up to take a break. Face the bad news when I get back.

I compile every single time I think that compiling will be successful, more or less. If I close a quotation mark or finish a rule or phrase, I compile. For me that might be a little less often than once per sentence because I have a habit of ripping things apart and writing big sprawling chunks at a time, and getting distracted before they’re finished. But if I’m not sure whether I followed up all the threads in my mind, I’ll compile and maybe test in order to check if I missed something.

I couldn’t get the Unit Tests package to work. Most of my testing ended up being a shell-script hack to replace the buggy skein. I did use Object Response Tests, and I wrote an Autoundo for Object Response Tests extension so that I could do some minimal branching within my tests. The Autoundo slows things down, though, and by the end of A Killer Headache, I was waiting 20 minutes for my tests to run. Along the way, I did some profiling - knowing in the back of my mind that online players would appreciate a little extra speed, but mainly concerned with getting my tests to run faster. I wasn’t able to improving things that much, but I did get a sense of where the hangups were (parsing, especially with Lost Items, plus some every turn rules), and I fixed some of that.

But I got exhausted with testing. I always intended to run Object Response Tests on every object in the game and in every room, but I never made it past the first 3 rooms (including 2 flashbacks). I just got burned out after that, reading through every single action response. Later on, more of the testing focused on known issues and parsing challenges.

I had an iteration cycle in mind when I was working: Write, compile, test, commit to version control. Unfortunately because testing and version control (svn) were so slow, I often got distracted and started adding to the code while they were running. Then I’d have to start the cycle over.