I need to build a scripting interface for my C# program that does system level testing of embedded firmware.
My application contains libraries to fully interact with the devices. There are separate libraries for initiating actions, getting output and tracking success/failure. My application also has a GUI for managing multiple devices and assigning many scripts to be run.
For the testers (non-programmers, but technical), I need to provide a scripting interface that will allow them to come up with different scenarios for testing and run them. They are just going to call my APIs and then return a result to my program (pass/fail and message).
A very basic example of what I want:
TURN_POWER_ON
TUNE_FREQUENCY frequency
WAIT 5
IF GET_FREQUENCY == frequency
REPORT_PASS "Successfully tuned to " + frequency
ELSE
REPORT_FAIL "Failed to tune to " + frequency
ENDIF
TURN_POWER_OFF
Where the reporting, power and frequency functions are provided by my C# libraries.
Will something like IronRuby or IronPython be good for this, or should I just build my own very basic language?
Does the Ruby/Python code get messy when trying to include a bunch of .NET compiled assemblies? I want it to be easy to learn and code for non-programmers and programmers alike.
EDIT:
Thanks for all the great responses. I chose IronPython as the answer since it had the most support, but I'll spend a bit of time with each of IronPython, Boo and IronRuby to see what the testers would prefer to write scripts in.
I agree with Marc G, though it's worth mentioning that the general concept is a Domain Specific Langugage. While IronRuby/IronPython aren't strictly domain-specific, they are full-featured and it would leave you to get on with your implementation.
Visual Studio has the DSL tools, and there's the 'M' Grammar stuff you can look into.
But yeah, IronPython.
I've heard very good things about IronPython for exactly this type of scenario. I'd certainly risk spending a few hours on a quick proof-of-concept, to see how it pans out.
Michael Foord will happily wax lyrical about the success of IronPython in similar cases (most specifically for him, for spreadsheet savvy users), and his book covers (IIRC) a few pointers about hosting it from .NET.
Irony could also be a good candidate here. Here is an example which creates animation for the given image on the fly.
The tutorial for creating such DSL is here:Writing Your First Domain Specific Language
It is an old tutorial but the author still maintains his library here: Github Irony
You may want to look at Boo, another managed language that runs on the CLR, and which is particularly well suited to build DSL and make your applications scriptable.
The compilation pipeline is directly extensible from the language itself.
Reading the Boo Manifesto is a good starting point if you want to learn more about it.
[Edit] I forgot to mention that Ayende Rahien is writing a complete book on the topic: Building Domain Specific Languages in Boo
It might be worth considering PowerShell for this sort of task. That can call into .Net just as any of the DLR languages, and has a more natural language type chunking for tasks in its cmdlet (command-let) concept. You have to write the cmdlets in a compiled language at v1 -- in v2 which is being rolled out starting with Win7 and working to older releases in the next few months (v2 for Vista/Win2k8 is at RC now), you can build those in PowerShell directly.
IronRuby is the most powerful for creating domain-specific languages, because it's syntax is much more flexible and forgiving than python's (your users are going to screw the whitespace up and get annoyed by the mandatory () to call methods).
You could write your sample script in IronRuby and it would look like this:
Here's a sample of a DSL our Testers are currently using to write automated tests against our UI
However, as things stand right now IronPython is much more mature and has much better performance than IronRuby, so you may prefer to use that.
I'd strongly recommend going with either IronPython or IronRuby over creating your own custom language... You'll save an unimaginable amount of effort (and bugs)