Now we have an emailTest object that's ready to have its options set. Below, we've covered every option that you might want to set before ordering your email test. 

 

Sandbox mode

The first and most important (at this stage) option is Sandbox. Setting Sandbox to true tells Litmus that you don't want start a real test that you'll be charged for, but instead start a mock test in our sandbox environment. Let's set Sandbox to true so we won't be charged for this test:

 

emailTest.Sandbox = true

 

A note for Perl developers If you're using Perl and SOAP::Lite, we strongly recommend using SOAP::Lite 0.65 or above (0.71 is preferable) as a bug exists with nullable types in earlier versions.

 

Specifying a UserGuid

You can run tests that are charged on a per-test basis, or those that are part of an ʻunlimitedʼ subscription. To differentiate between these two types of tests for billing purposes, you either include or exclude a unique user identifier, or “user GUID”. If you do not include a user GUID, you will be charged for that individual test. If you do include a user GUID, that test will be counted as part of a subscription. 

 

At the end of each month we will collate the number of unique user GUIDs for your account, and that will serve as your number of active subscription users. 

 

To understand how to generate user GUIDs, and how to send that information to us when you create tests, see Generating User GUIDs. 

 

In our case, we're not going to assing a UserGuid because we want to pay per test (although it doesn't matter yet because we're in Sandbox mode, so no tests are chargable anyway).

 

Selecting email clients 

Another thing we'll probably want to test is what email clients are test should use. There are two ways to do this. The first, and by far the easiest, is to simply do nothing. When Litmus sees you've not supplied any clients to test on it'll automatically use all available clients for your account.

 

However, if you'd like greater control, Litmus' Web Service supports that too. Our emailTest object has a Results collection. Results is a list of Client objects. Adding clients to it before you order a test will let Litmus know that you only want to test on those particular clients. Here's some psuedo code that will take our existing emailTest object (created above) and select just two clients for testing; Outlook 2003 and Gmail (new).

 

// Create our list and make space for two clients
emailTest.Results = new Client[2]
// Create a Client object within the first space
emailTest.Results[0] = new Client
// Assign Outlook 2003's ApplicationName to that new Client object
emailTest.Results[0].ApplicationName = "OL2003"
// Repeat for Gmail (new)
emailTest.Results[1] = new Client
emailTest.Results[1].ApplicationName = "GMAILNEW"

 

Remember, you only need to do this if you want to select specific client(s) to test on, it's usually much easier to leave emailTest.Results emtpy and allow Litmus to fill it in for you.

 

Finding all available email clients

At this point, you're probably wondering where to get those ApplicationName values from. We've created a special method to return all Client objects available for your API account with one easy call to be used during development. Please do not use this method before each test, it's designed for use during development only.

 

The example code below fetches all available Client objects for a ficticious API account and then outputs them to a console window.

 

availableClients = LitmusApi.GetEmailTestClients("api-key", "api-pass")
foreach (client in availableClients)
Console.WriteLine(client)