- OVERVIEW
- Languge: C#
- IDE: Visual Studio Code
- Source Code Management Tool: Github via Github Desktop
- Type of Tests: NUnit
- Website Tested: Restful Booker API and Restful Booker UI
In this post, I want to continue to walk through my long-term goal of creating a test automation portfolio. This time it is a bonus section, because it wasn’t in my original set of tasks to include NUnit testing. However, I’m a big believer in not trying to reinvent the wheel, and after taking Brendan Connolly’s excellent NUnit testing course on Test Automation University I was able to get a copy of his code working which meant there is a repository there for me to dip into in future. I was also able to discuss my progress with Brendan, who was really helpful, so thankyou for giving me your time.
My aim with this code was 2 fold:-
- To get it working with the latest nuget packages, selenium version etc. (parts of the original codebase were probably a few years old)
- To make as many of the tests as possible pass and improve my learning by making slight modifications to the codebase
The Project
As I said before, this was pre-existing code from Brendan’s TAU course on NUnit, which I highly recommend. It used the popular training site Restful Booker to show off lots of NUnit functionality, via tests which predominantly Added Rooms. In addition some introductory tests were standalone on key functions e.g. Equality Assertions.

So, what does it do?
There are lots of test cases here (in fact I had to reduce the numbers to make it a little clearer). The tests use data driven tests to read external data sources (among others) to provide test data for the tests. There are also a couple of API tests which create a booking and get a booking using the RestfulBooker API.
Key Features
Whilst the number of tests written into the code were few, because of the selection of test data and parametisation the actual number of tests was over 100 – this will come in useful if you want to rerun a test with different inputs. Asserts were used to verify test results. One cool feature that I liked was [pairwise] which, when inserted as part of the [Test] definition, allowed a sensible set of combinations of test data to be created automatically to avoid millions of tests when, say, 3 or 4 different fields have been specified.
For accessibility purposes (thankyou for the schooling @UndevelopedBruce !) , I include an extract of the code alongside a screenshot of Visual Studio.
[Test]
[Pairwise]
public void AddRoomWithValueSource(
[Values("9","88")]string roomNumber,
[ValueSource(typeof(TestData),nameof(TestData.CurrencyStrings))] string Price,
[Values]bool accessible,[Values] RoomType roomType)
{
var originalRoomsCount = adminPage.GetRooms().Count;
var room = new Room()
{
Number = roomNumber,
Type = RoomType.Family,
Price = Price,
Accessible = accessible,
HasWifi = true,
HasView = true
};
adminPage.AddRoom(room);
var rooms = adminPage.GetRooms();
var createdRoom = rooms.Last(r => r.Number == room.Number);
Assert.Multiple(() =>
{
Assert.That(rooms.Count, Is.GreaterThan(originalRoomsCount));
Assert.That(createdRoom.Price, Is.EqualTo(room.Price));
Assert.That(createdRoom.Accessible, Is.EqualTo(room.Accessible));
});
}

The Code
I don’t want to give anyone false expectations of my supposed awesomeness here. To be frank, there is no way I would consider myself able to write this code myself (yet). What I was able to do was modify it, get it working, (mostly) understand it.
You can find the code on my GitHub Repo here.
Lessons Learned
In doing this I learnt a few very valuable lessons.
- Noone is above making mistakes
- People really want to help you out (even super duper leaders in their fields that you assume are completely untouchable), you just need to ask for it
Lesson #1 Everyone Makes Mistakes
So herein lies a story. I tried to get all of the tests in this repo which were supposed to pass (some were intentionally failing) to pass successfully. One test in particular was just impossible for me to understand. I tried debugging, I tried adding console logs to check the values, I tried watching it running and I had no idea why it failed. I assumed as the code was from a mighty instructor that it must be something that I’ve done to it thats the problem. I checked the code against the original .zip file and it was exactly the same.
So, completely stumped, I took to Twitter and asked for help.

Twitter is just magic. Within half an hour I’d received this – from the amazing Mark Winteringham – the self same guy who wrote the Restful Booker site I was trying to test.

It suddenly made perfect sense – it was the code which wasn’t right, not me! I checked his theory out by running the test and checking the first value in the list which appeared, and lo, it was that false value which was being read, not the value of the newly created row. I quickly updated the code to read “Last” instead of “First” and re-ran it. The relief at seeing that pass tick was palpable.

The course code was focussing on teaching other elements, and as this test wasn’t modified the issue was never exposed during the course itself. Mark’s reply to this is a lesson I will take with me for a long time.

Everyone makes mistakes.
Lesson #2: Ask for help
This is all tied in with the above story and quote. Its easy to think of people as above you and feel like you are bringing them a silly question that is beneath them to answer. But the truth is I think people actually love being able to answer questions, and if they know the answer straight away and it helps someone out then it actually makes them more likely to respond, not less. Also, people are generally helpful and lovely and that’s just the way it is so there inner saboteur. :o)
3 thoughts on “Creating A Test Automation Portfolio Bonus Episode: NUnit testing of Restful Booker”