distributedlife

If your service implements security then you will need to include security configurations in your script. For basic HTTP authentication you can use the web_set_security method but for more complicated work you are going to create a protocols.config for your service request.

For any non-trivial service testing instillation you are may have to support multiple service bindings and authentication mechanisms. Multiple these factors across services and endpoints and you start getting a configuration nightmare.

The solution of course is to generate the protocols.config file dynamically. I’m not going to provide a tutorial on how to generate this file. It’s dependant on your services and the environment you work in. I’ve only generated configurations for the three or four bindings we cater for. I’ll assume you can do the same.

What I am going to talk about is getting your actual test script so that it reads better when you combine security.

I like the fact that our tests look like this:

ExecuteTestAsUser (MyServiceUser) ;

SetDefaultParameters () ;

CallService () ;

It’s a simple setup that makes your test readable and more robust. ExecuteTestAsUser is responsible for taking the identifier for a service user. We allocate one user per service. We do this because you are going to iterate through multiple security combinations (has access, no access, super user, banned, etc) if you had users set up in those security combinations and you attached identity specific data to the user you have the potential to disrupt other tests running at the same time.

So it’s better to give each service a specific user and at the start of each test have code like so:

GrantSuperUserToUser (MyServiceUser);

The implementation of such a function is dependent on the authorisation and authentication mechanisms in your environment.

Your users should be setup in an enumeration like so:

enum UserScenarios
{
    DoNotSetSecurity,
    MyService1,
    MyService2
}

This helps to keep your user accounts type safe. You won’t misspell the username in your tests. Use a look up table to get to your username and passwords:

char* usernames[] =
{
    "User001",
    "User002"
}

char* passwords[] =
{
    "PASSWORD",
    "PASSWORD"
}

The point of all this is that when you call ExecuteTestAsUser you can query the lookup tables using your identifier to resolve the username and password. This information is required for both web_set_security and protocols.config.

There is one caveat with protocols.config but I’ll discuss that tomorrow as there is no workaround as yet.