# Chapter 3.6 - Data




Transcript lesson3.6-coverimage.png

Overview: In this lesson, we cover the final part of our POISED testing strategy, which is “Data"

Note:

For maximum benefit, please view the course video for dynamic demonstrations.

The final part of our Poise testing strategy is data. The Restful Booker API, and many other APIs, are at heart data handling mechanisms. They're creating data, they're storing data, they're modifying it and they're passing it around to different services and applications.

Making sure that the data is being handled properly is a very important part of testing APIs.

For example, when we create a booking, and we'll just create the default we’ve been using again:

{
	“firstname” : “Jim”,
	“Lastname” : “Brown”,
	“totalprice” : 111,
	“depositpaid” : true,
	“bookingdates” :  {
		“checkin” :2018-01-01,
		“checkout” :2019-01-01},
	“additionalneeds” : “Breakfast”
}
1
2
3
4
5
6
7
8
9
10
11

It's not enough to just say, "Well, we got a 200 OK and a response back." You have to actually take this ID, the new ID, and GET the booking by ID and make sure that it's actually there. In this case it’s:

 {{rb_url}}/booking/21 
1

You can make sure it's actually there by checking the database directly or by calling the API. The point is, don't just trust that the response is doing what it's doing. Actually make sure that the data is where it should be.

Another important part of data handling is making sure that you're collecting the data that you need to have.

For example, when we're creating this booking, we have a price of, in this case 111, but we don't what. Is it 111 dollars? Is it 111 Euros? Is it 111 rubles? We really have no idea. If this was an international API, this number, 111, is useless without a currency indicator, so that's the sort of thing where you have to think about—not only are you handling the data correctly, but are you collecting the right data?

The last data aspect I want to talk about is scalability, so that's asking the API if I have a thousand bookings in this database, will I be able to perform all my functions quickly enough?

What if I have 10,000? What if I have a million? This is a data-related challenge that's very important to consider in any API that's going to have more than one or two users. For example, currently when I search for bookings by name, it returns in 11 milliseconds.

But what would happen if I added a thousand more bookings to the database? Would it still be 11 milliseconds? Let's find out.

So what I'm going to do here is I'm going to create a new collection, and we'll call it Create Booking, and just create that, and then we can just copy our Create Booking request into our new collection with copy/paste, and then we open it up in the collection runner. We'll go more into this in the next lesson, but this is something that will run the entire collection.

In this case, our collection only has the single request to create bookings. Remember, our goal is to add data to the database and see if we can still perform properly. Let's go ahead. We're going to run this locally and we're going to do it a thousand times (by entering 1000 into the Iterations field on the collection runner. Then we hit the button at the bottom and we run.

So our test run is complete, and we have a thousand new bookings in the database. Now let's see how quickly our find is working. It was 11 milliseconds before, and it's still 11 milliseconds. That's pretty good, but you would want to test it again with even more bookings, because really a thousand pieces of data is not much for a production API.

These are just a few aspects of data handling that you can consider when you're testing your API. Now that we've gone over our full test strategy, in the next lesson we're going to bring it all together and finally write some test automation.


Code Resource