Code Tests Wishlist

This week I continued working on implementing the code tests using Aaron’s interface. Although Aaron has made a really awesome system, there is nothing like actually trying to use a system to reveal things you may not have considered before. Since I know that the interface is bound to change, I decided against writing a test for every skill now, but rather trying to write a sample test for the different categories of skills and any outliers. Thus far, I have worked on writing a test to check for the presence and implementation of a JavaMethod (“Say”, “Think”), a test to check to see if more than one character has been animated, and I am working on a test to check for the correct use of an action order box (“Do Together”). Along the way, I’ve been taking note of what implementation issues that I’ve been having and compiling a wishlist of things I would like in the interface. Here is a brief summary of some of the conclusions I’ve come to.

Wishlist

• A way to filter out code that is disabled.
• A way to check whether or not a user method is called in myFirstMethod(). (My tests give false positive when a passing construct is in a userMethod that is never called.)
• A way to isolate the code from Scene Setup. (This is potentially related to the previous wish. Besides being useful for the tests I write for the Scene Setup badge, I think distinguishing between UserMethods, myFirstMethod() and Scene Setup will also be helpful for the mentors writing code tests. Although I know that scene setup behaves like any other code the user writes, that is not apparent to someone who doesn’t know the guts of Looking Glass since the IDE keeps the two separate.)
• A way to check and see if the code comes from a remix. (This is important if I want to distinguish between a remix a full badge).
• A way to see what actions the user has taken while making their world. (This would be things like playing the world, or zooming out during a remix. Although these were skills when Caitlin and I were first thinking about badges, I know that the test for these may be hard to implement, and we may need to restructure the criteria for these).

Besides thinking about the design of Aaron’s stuff, writing the test has also brought up some complications for badges stuff. For instance, in writing the test for the animating multiple characters skills, I had to think about what defines a character and what defines an animation. I concluded that a character was anything (including props) that you could add during Scene Setup. Although a desk may not be included in the traditional definition of character, in LG it can still have actions, and the point of the skill is to have more than one thing in your world do an action. As for animation, for the most part the given JavaMethods (“Say”, “Think”, etc) qualify. Even things like “Set Opacity” and “Resize” qualify as animations since they show a change in the character and I can think of a case in which one character casts a spell and the other changes color - which would qualify as animating multiple characters. However, I did decide that “delay” wouldn’t qualify as animating a character since if you used “delay” and nothing else, then your character really wasn’t doing anything... and you aren’t implementing delay correctly.