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!


10th Annual Ann Arbor GiveCamp is just 2 weeks away!

I can’t believe it’s only 2 weeks until the 10th Ann Arbor GiveCamp!

I’ve been volunteering with GiveCamp (Lansing and Ann Arbor) since 2010, and keep coming back because it is the BEST volunteer experience ever. Sure they’re long days, some hard problems to solve, things to prioritize, usually lots of caffeine and sugar (I can’t have caffeine anymore but sugar! SO MUCH SUGAR!).

I’ve written about GiveCamp a few times before, and why it’s so important.

The past few years, I’ve lead teams which has been great but also terrifying. You’re leading a group of strangers through a complete software project in a weekend! Weeeeee!

I’m excited to be back at WCC with my pals, doing it all again in 2 weeks.

And you can join us! We are still looking for volunteers and I think 1 or 2 more days for non-profits to apply as well!

I’ll probably do a recap post when it’s all done and I’ve caught up on sleep 😀 Hope to see you there!

I have seen the future…

I get involved in a lot of things around technology, especially with kids in Detroit. I love being able to help these kids not only see a future in technology for themselves, but to help them get there.
I became the Vice Chair of the Information Technology Pathway Advisory Board for Detroit Central High School in December of last year. In that role, I’m helping students at Central indirectly – mostly via finding learning opportunities, funding, and advising on curriculum.
A project the sophomores had from March centered around Autonomous and Electric Vehicles, and pulled in curriculum from Computer Programming, Chemistry, Geometry, Art, and Government. The students, in teams of 4, had a few tasks to complete, with the best team taking home some sweet prizes.

  • Computer Programming – Students will assemble, program, and market an Autonomous Vehicle using Lego MindStorm.
  • Chemistry – Students will investigate the pros and cons, efficiencies and inefficiencies, of using battery powered vehicles by assembling battery powered motors.
  • Geometry and Art – Students will design and build a to scale city for test driving their autonomous vehicles.
  • Government – form arguments for/against mock proposals supporting Autonomous and Electric Vehicles

The students had field trips to the M-City autonomous testing location in Ann Arbor and  the GM Battery Lab, and had industry experts join them in the classroom for Q&A.

All of this work culminated in a symposium, held last week. Students presented their work science-fair style, and all of the city blocks they built were placed in the center of the room where the cars were test-driven. Visitors were to go around to each team’s table, hear their arguments and observe their autonomous cars, and vote on who had the best car company, the best designed city block, the most persuasive presentation, and the best overall presentation.

I can’t tell you how impressive this was. These students are pretty amazing! They built the cars, did some programming on the fly, created brands for their cars, stood professionally at their tables and argued their cases. The big winners each got to take home a laptop!

I love working with this school, and feeling like I’m helping to make a difference for them. These students can see, from this symposium, that the community cares about their success, and wants the best for them. I can’t wait to see what we plan for next year!

This slideshow requires JavaScript.

In this video, the students were testing out their vehicles before it was “official” – obviously some reprogramming needed to happen for some! We’ve all been there, though! I reassured some students that I know exactly what it’s like when your code works one minute then it doesn’t as soon as someone else looks over your shoulder 😉

KalamazooX 2018 Recap


KalamazooX is over. Most likely won’t be another one. Not sure what will be able to help me like it has now, but we’ll see.

It’s not just a conference, it’s all of the people that I get to see. Sure I see them individually or in sub-groups other times of the year, but seeing everyone together also makes this special. Seeing my IT family all together, once a year. I hope we find other opportunities to all get together.

Below is the link to the Storify of my live tweeting of KalamzooX 2018. It was remarkable in that at one point, my Twitter account got locked out and I had to prove I wasn’t a robot. I blame Leon Gersing and his insane quotability 😉

Here’s the link:

Kalamazoo X – the last of its kind & an offer

The last Kalamazoo X conference in Kalamazoo is taking place on April 21st of this year. I’m sad to see it go, but excited to see what it evolves into.

I started attending Kalamazoo X in 2012, and I’ve attended every year since. It is a life-changing conference in so many ways!

I’ve written a blurb in the past (here: BestConferenceEver = KalamazooX) to get people to check it out. I live-tweet and then compile every one of them I’ve attended since 2015 (KalamazooX 2015 recapKalamazoo X 2016 Recap, and Kalamazoo X 2017 Recap) if you want to get a feel for what it’s like.

I decided that even though I feel like it’s a super cheap conference (only $75 at top price!), some people may still not be able to make it work. I’ve been there, when $75 meant way more than a day of sitting at a conference.

So I want to make an offer to the community – if you want to attend Kalamazoo X this year but can’t for financial reasons, I will buy you a ticket. I’m able to cover 2 people.

But I encourage anyone out there that has gained understanding of the world and themselves, like I have, from this conference, to do the same.

So, let me know if I can help you. Email me – g33klady at gmail dot com – and I’ll hook you up. I believe in this conference that much. And I want as many people to benefit from it as possible!

A Lesson From My Testing Journey

On February 20th, I shared my career journey for the first time to a large audience. I gave a Ministry of Testing Masterclass called “Not All Who Wander Are Lost: A Career Experience Report” (a recording is available for Pro Dojo members here:

I’ve had kind of a wonky career path, and have at times felt some shame for “going backward” from a test lead to “just” an engineer. Now, though, I feel pretty good about my journey – I wouldn’t be who I am today, or where I am, if not for those experiences.

One lesson that I touched on, but I’d like to reiterate here, is to be honest with yourself about what you want to do.

I’ve had testers come to me and ask what their career path should look like, or what they should be aiming for. “What should my end goal be?”

Your career goal is for YOU to decide! Don’t let others make your life plans for you!

For sure, ask for advice about others experience. You don’t have to be a manager. You don’t have to be an architect. You DO have to be happy and fulfilled and grow and learn and get value and give value in your role. I can’t tell you what that looks like for you. Hell, I don’t know what it looks like for me! I’m taking my career a day at a time!

It’s great to have goals, but please, keep your goals flexible! If you realize on the way to becoming a manager that you really want to stay hands on, do that! It’s not the time to stick to your guns like “well, I wrote this down, I have to do it”. Your career should make you happy!

Every day, your experiences change you. You are a different person today than you were when you started your career.

Be honest with yourself about what you want from your career. You might wander a bit, but you won’t be lost as long as your true goal is happiness.


Codemash 2018 Recap

It’s taken far too long to put this together! Here are my Storify posts of my live-tweeting the sessions from Codemash January 9-12 2018!

Precompilers (Day 1 and 2):

  • Build a Natural Language Slack Bot for your Dev Team with Michael Perry
  • 3D Printing Lab
  • The Hidden Requirements: Exploring Emotions with Placebos with Damian Synadinos
  • 3D Modeling For Makers and Game Developers with Robert Palmer

Day 3:

Day 4:

  • I have people skills! The Importance of Emotional Intelligence and Your Career! with Michael Eaton
  • Sondheim, Seurat and Software: finding art in code with Jon Skeet
  • Advanced Patterns for Automated UI Testing with Seth Petry-Johnson
  • Leadership Lessons from World of Warcraft with Ish Amin

We left early as a stupid snow storm was coming in and we needed to get back home.
Another great CodeMash, lots of new stuff for me this year. Looking forward to next year!

24 Hour Hackathons… with dinosaurs!

I recently participated in my company’s 24 hour hackathon. I pulled together my tweets on Storify here:

It was a super cool experience, and I’m looking forward to learning more 😀