Monthly Archives: October 2018

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!

public void VerifyGetTodoItem1ReturnsCorrectName()
     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

     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.AreEqual(expectedName, actualTodo.Name, "Expected and actual names are different. Expected " + expectedName + " but was " + actualTodo.Name);


public void VerifyGetTodoItem1ReturnsCorrectName()
     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

     IRestResponse actualTodo = client.Execute(request);

     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; }

    public string Name { get; set; }

    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!


TestBash Manchester Tweets!

I finally got around to putting all of my tweets from TestBash Manchester, and Test.Bash(); into a Twitter Moment! They are here:

Note that the Test.Bash(); section is a bit light because I was very nervous about my talk, and went to the quiet area to review/tweak it during some of the talks. I’m sorry to have missed them in the moment, but I’ll watch them on The Dojo when they’re available!

Testing the UI and API together with my new practice app!

It’s been a bit quiet lately, and that’s because I’ve been very busy with creating a workshop and new talk for TestBash Manchester! Now that it’s done, I can finally blog about some of the stuff I did to create the workshop, and release an app for folks to practice with!

Understanding The Problem

I have previously done a workshop on testing REST services, where I wrote an ASP.NET Core 2.1 API with a simple web front-end (using the Todo API example as a base to start from). For that workshop, participants would load up the code in Visual Studio and run the solution locally. This was a no-brainer, as part of the workshop was to write some automated tests in Visual Studio.

However, for the workshop at TestBash, I needed to account for an audience with a wider range of skills – I had done the above workshop at developer conferences and at work. Discussions with the folks that run the conference suggested a workshop without needing to code, to accommodate the most attendees.

So I realized I could use what I had written, and develop a workshop testing both the API and the UI that went along with it. We could test using Postman, Swagger, and dev tools in the browser. That could easily go 4 hours! Perfect!

But then I had a problem – how was I going to provide this application to the participants? I could host it somewhere – I tried putting it up on Azure, and it worked! But what about when one of the participants did something catastrophic to the data in the application? That could cause a whole host of problems, having shared data when asking participants to really try to break an application individually…

So what I really needed was to again have each participant running the application on their own machines – their own instances of the application.

Docker To The Rescue!

The obvious choice from there, for me, was Docker. I hadn’t worked with it too much on the “creating images” side, but had worked with it as a consumer of images.

I found some documentation on how to Dockerize my application but at one point, when right-clicking on the project in Visual Studio and selecting Add, I saw “Add Docker Support” so I clicked it! What could go wrong?


It asks you to target an OS – Windows or Linux. I chose Windows, because I’m on a Windows machine. And once you click OK it creates all of the Docker files for you! It’s pretty awesome! I compared the documentation to what Visual Studio automagically created for me, but it looked all good.

I followed the steps to build and run the image, and it was up and running! Awesome!

Then I had to get it to the participants somehow. I found this documentation on sharing your images, followed the steps and I was able to pull down my new image on another machine!


While I was prepping the prerequisite documentation for my workshop attendees, where they set up Docker and Postman and Chrome, I realized I needed to have people set their Docker configuration locally to run Windows images. After looking through the documentation, I found that folks on a Mac would not be able to run my image! Ack! Now what?!

Well thankfully, ASP.NET Core 2.1 applications can run on Linux equally as well as they can run on Windows! Yes! So I just had to set my local Docker config to run Linux machines, make a few modifications to the Dockerfile, build and publish it again. And now my application was accessible on Windows, Linux, and Mac machines without issue!

Now For The New App!

Ok, so now that we’ve got it all figured out, I can share the details for how you can use this Docker image to practice testing!

You can run the image locally, and have your own instance of a REST API and web UI to mess around with. This application has a Swagger for the API, and it can be reached via Postman as well as other tools.

It has a few known bugs (I’m not documenting them because that’s part of the fun of the workshop!) and quirks. If it ever gets in a bad state for you, simply stop the image, and start it up again! Remember to stop the image when you’re all done with it for the day – it does take up some resources on your computer.

Source code for the application can be found at

The information to get it running is in the Readme of the repo, here:


Once Docker is running, the application can be accessed at http://localhost:8080.

Swagger specification can be found at http://localhost:8080/swagger.

I hope you enjoy! Watch my website or twitter for where I’ll be giving this workshop next, as well!