Transcript
Overview: In this lesson, we are going to cover the first part of our POISED testing strategy which is “Parameters.”
Note:
For maximum benefit, please view the course video for dynamic demonstrations.
Let's look at one of these API's. This is going to be the Create Booking. When we're doing parameter testing, we're testing each of these values.
{
“firstname” : “Jim”,
“Lastname” : “Brown”,
“totalprice” : 111,
“depositpaid” : true,
“bookingdates” : {
“checkin” : “2018-01-01”,
“checkout” : “2019-01-01”
},
“additionalneeds” : “Breakfast”
}
Each of these is a parameter in the booking application. We want to make sure, first of all that the valid values work.
We're basically going to be doing classic boundary style testing on these parameters.
For example, what if we have an an empty string in the first name parameter? That causes an error. Now we know something more about the program.
What if it has spaces in it?
“firstname” : “dsfs sdfsd dfs”,
That's okay, and doesn’t give an error. Now we know something else.
Different parameters are going to act differently. For example, if additional needs (additionalneeds) is empty:
“additionalneeds” : “”
That's fine. What happens if the field is null, what happens then?
“additionalneeds” : null
That's also okay.
What if we don't have this at all? Deleting the parameter from the code still works without any errors. Obviously the additional needs is completely optional and there's not really any controlling what's in it.
Whereas the first name parameter has to have some value. What if it's just a single letter?
“firstname” : “J”,
Then that's fine as well. Now we've learned that the first name has to be a non-empty string, whereas the additional requests value is completely optional.
The other thing to look at is whether an invalid value causes a problem.
There's no type checking in a JSON package (package.json) that's going through HTP.
Even though the deposit paid parameter is boolean, I could easily make this a string. It doesn't even have to be a string that matters. It could just be anything and we would get a valid result.
“depositpaid” : “ksdjflskdjfsldkjsf”,
It could even be a number, that will work as well and we will get a result that says our deposit was paid. That's interesting.
What if it's an empty string?
“depositpaid” : “”,
Oops. That causes an error.
We have all sorts of interesting things here going on with the deposit paid. A random string causes true, but an empty string causes an error.
This is the sort of testing that you can do on the parameters for your API's to find out how it reacts under different conditions.
# Code Resource
Quiz:
Note: Chapter 3 has been divided into multiple sub-chapters. You'll find the Quiz on the last sub-chapter, Chapter 3.6. Read on!
