Implementing RestSharp in REST API automated tests

I have written before a few times about implementing automated tests for REST APIs using C# (here and here). In those posts, I’ve used a utility method to handle the actual sending of the HTTP request, and another one to read the response. These methods help to illustrate what our automated tests are actually doing.

However, I don’t think I need to be bothered with all of that all the time. Generally, in an automated test suite, you don’t want to be building everything yourself from the ground up. Actually, that goes for most things we’re building – that’s why libraries exist!

So I looked into a NuGet package that would do what I wanted, and found RestSharp. Using RestSharp really cleaned up my code! For one, it got rid of those utility methods. And let’s be honest, I’m not the most amazing C# developer, and I’m sure there were issues with those methods. And it combines the request to the API and the deserialization of whatever came back all in one line of code, so my tests have fewer lines of code as well. I just needed to add the RestSharp NuGet package to my test project, and add the reference.

Let’s take a look at the before and after!
Before

[Test]
public void VerifyGetTodoItem1ReturnsCorrectName()
{
    //Arrange
    var expectedName = "Walk the dog"; //we know this is what it should be from the Controller constructor

    var url = _baseUrl + "1"; //so our URL looks like https://localhost:44350/api/Todo/1

    //Act
    var response = Utilities.SendHttpWebRequest(url, "GET"); //get the full response
    var respString = Utilities.ReadWebResponse(response); //get just the response body

    TodoItem actualTodo = JsonConvert.DeserializeObject(respString); //deserialize the body string into the TodoItem object

    //Assert
    Assert.AreEqual(expectedName, actualTodo.Name, "Expected and actual names are different. Expected " + expectedName + " but was " + actualTodo.Name);
}

After

[Test]
public void VerifyGetTodoItem1ReturnsCorrectName()
{
    //Arrange
    var expectedName = "Walk the dog"; //we know this is what it should be from the Controller constructor
    var client = new RestClient(_baseUrl);
    var request = new RestRequest("1", Method.GET); //so our URL looks like https://localhost:44350/api/Todo/1

    //Act
    IRestResponse actualTodo = client.Execute(request);

    //Assert
    Assert.AreEqual(expectedName, actualTodo.Data.Name, "Expected and actual names are different. Expected " + expectedName + " but was " + actualTodo.Data.Name);
}

True, I only saved one line of code. I could save another by putting the instantiation of the RestClient in a method that’s called before each test. But I’m also removing another dependency from my test, since the deserialization is being taken care of by RestSharp.

One thing to note here is the difference when the object is deserialized.
Let’s take a look at our model for the TodoItem referenced in these tests.

public class TodoItem
{
    public long Id { get; set; }

    [Required]
    public string Name { get; set; }

    [DefaultValue(false)]
    public bool IsComplete { get; set; }

    public DateTime DateDue { get; set; }
}

When a TodoItem object is deserialized using JsonConvert from Newtonsoft, we can access properties as we’d expect. For instance, if we wanted to get the name (as in the test example above), we access it like so:

TodoItem myItem = JsonConvert.DeserializeObject(respString);
var itemName = myItem.Name;

However, RestSharp puts the deserialized object into a Data property. So we need to access them via Data. Like so:

IRestResponse myItem = client.Execute(request);
var itemName = myItem.Data.Name;

Just something to be aware of when changing how things are deserialized!
I’ve implemented RestSharp in a branch of my TodoApi repo, and kept it as-is in the other branches, so you can compare implementations.

Have you found another way to test REST services with C# than RestSharp or home grown solutions? Let me know in the comments – I’d love to see what you’ve got!