In my current assignment I´m working on writing a non-functional test framework.

I´ve been pushing very hard for implementing and supporting a DSTL (Domain Specific Test Language) since it´s my belief that in doing so we can have more testers focus on writing actual test cases without having to worry about the implementation.
Also I´ve been itching to get an excuse to implement my own DSTL for a while ;-)

A test case could look something like the example below and can be written in either a text file or a spreadsheet (or anything else for that matter, wiki page etc etc as long as you convert it to a format the server understands).

Configure simulator | on sim1 | using traffic_type1
Start simulator | on sim1 | with 800 calls/second
Start CPUProbe | on $[sut1]
wait | 20min

The first column/cell is the actual test command and the following columns/cells are parameters to the command.
In the text file we have currently chosen to use a pipe-sign for clarity.
Notice how the test commands reads out as almost normal human sentences.

A clear benefit of this approach is that the test cases have a higher chance of being:
- Clear and obvious, even to other stakeholders
- Robust and requiring less maintenance, since we separate test purpose from implementation
- Lends itself naturally to becoming data-driven

As you can see in the "Start CPUProbe" I have actually taken one of the parameters and indicated (with the dollarsign) that this should be replaced with data from some external source, like another data file, database or perhaps some wiki-page.

Now when you send a test case like that into the test server you have to map the test command to some function/code that is going to be executed.

This weekend I had some time to think on how I could solve this in an elegant way, and I really didn´t wan´t beeing stuck in an endless if/else or switch case story.
I wanted seomthing that would later be easy to use for dynamically adding new test commands/plugins in runtime.

The server is written in java and so what I came up with was defining a hash map with the test command as the key and then the fully qualified classname as the data.
Then I could use that hash map when a test command was sent to the server to use a dynamic class loader and instantiate a test command object.
The requirement for the test command class is that it is a child class of "TestCommand" which through an interface specifies that the Run()-method has to be implemented.

Here is an example of the code I used for the solution.

public class TestClass
{
private Hashmap m_cmdClass;

public Testclass()
{
m_cmdClass = new Hashmap<string,>();</string,>
m_cmdClass.put("Start simulator", "my.server.testcommands.StartSimulatorCommand");
}

public TestCommand getTestCommand(String aTestCmd, String aTestParamsBuffer)
{
TestCommand testcommand = null;
ClassLoader classLoader = Thisclass.class.getClassLoader();
String fullClassName = m_commandAndClasses.get(aTestCmd);
Class aClass = classLoader.loadClass(fullClassName);
testcommand = (TestCommand)aClass.newInstance();
testCommand.loadParameters(aTestParamsBuffer);
}
return testcommand;
}

So this code is just an example of how you can use a dynamic class loader and a hash map to connect a test command to an actual class.
This production code looks a bit different and there is error handling as well, but this should give you some ideas what you could do.