Script Engine operational

I think I'm all done with the embedding of the script engine itself. I have tests that are able to execute scripts by calling them by name at the JMXTerm command line. I decided to allow both no file extension and .groovy file extension, both callable by just the script name with no extension. Some editors, such as eclipse, fare much better when dealing with files with extensions as opposed to no extensions. Its a small thing might be nice for people writing scripts.

Next up is to decide what actually goes into the script binding to be made available to the scripts for use. Each command has access to a Session object which keeps track of all sorts of things such as open JMX connections, output and input streams for the command. Some of this would be useful to put in the binding for the scripts. The binding is a map of variables that are available to the script for use. Right now I have a variable called "out" which is the Session output stream. It allows things like

out.println "This is some output"

I could just use println to have it go to stdout, but that would not work when the Session explicitly sends output to a file and it also makes testing harder. Capturing stdout for the test is annoying whereas getting the output from the test session in the command under test is easy.

So now I go back the proposal and decide what is required to be available in the scripts and how to get it there.

Test Automation. Duh.

I haven't done too much since the holidays and I was having a hard time focusing again and I finally realized why. My testing sucked.

While embedding the GroovyScriptEngine into JMXTerm I was writing unit tests for all of the new classes and updating old test classes where I was modifying existing behavior. This was all fine, but then when I went to try out my new embedded engine with test scripts I would start JMXTerm and try running the commands that the scripts would implement. Sometimes it would work, sometimes it wouldn't, but every time it was a real pain.

I finally realized that I needed higher level functional tests that simulated me typing at the command line in addition to the class level unit tests.

There is a method on the CommandCenter class where all of the arguments typed in to the command line or passed in through stdin are processed. I not have a set of static test utility methods that can take a command line and run them through the entire application. After execution the test methods verify that the output from the script matches some regular expression and that the boolean return value of the execute() method is as expected.

This was really easy to do but it didn't dawn on my that I needed more than just class level testing to make it all work. I spend a lot of time at work selling people on automation. I guess I need to yell at me too.

I don't do any more manual testing of the command line and I love it. Developing is way more fun when there isn't one really annoying step in your workflow. Anyway, back to actual work.