Create the assertions that you need to check that tests are doing what they are supposed to. Learn how to use them for notifications when things go wrong in the API.
- [Instructor] We've looked at how to create and set up various kinds of tests, but we've been leaving out one very important feature. We haven't been checking anything. We've been sending API requests and then manually looking at them which is great when we're exploring. But if we want to run automated tests, we need to automatically check for failures. Now SoPI, of course, let's us do this. So let's take a look at how we can create assertions. So I've got a test step open here and down at the bottom we have this assertions tab. So let's open that up and let's add an assertion by clicking on this screen button here, and the first one we'll look at is this contains assertion. So it's pretty straight forward. We'll click on it, and then we'll add it, and what this contains assertion does is just checks for whatever text we put in here and makes sure that is in the response. So in this case, let's put Australia in there, and that should be in the response. We see it there, so let's hit OK, and if we look at this assertions, it has already marked it as green. It said that it's valid. So its automatically checked that assertion immediately for us against this response, so Australia is in this response and every time we run this test step after this, it will check again and make sure that Australia is in the response. Let's look at another one. So let's look at this JSON path existence match, and we'll add that. What this one does is lets us kind of dig into JSON a little bit more, and on this case we have very simple JSON so its not too difficult, but if you had nested JSON, you could dig into it that way as well. So the first thing we need to do is actually get a handle on the JSON, and we can do that using dollar variable. So what the dollar does is gives us this entire JSON map, and then we can drill into it using the dot notation. So we'll say dollar dot, and we can give it one of these key names. So let's use this Daylight's Savings one. So we'll say dollar.DST, and that will give us this variable here, this key and this value, and the expected result in this case, the value of this, is true as we can see here. So let's just test this, make sure its working. It says it matches which is what we would expect. Let's also just try the negative test and see to make sure it fails if we set it to falls, and indeed it does. It says the actual value is true and you are saying it should be false and its failed. So let's set this back to true since that's what it really is. Let's save it, and once again down here, you can see that its checked for us immediately. Let's look at another JSON one as well. So we have the JSON path count. So we'll add that one, and it's similar to the other one. We use this dollar and let's say dollar.dst, but in this case, we're not looking at the value itself. We're looking at how many items are here. There's only one item here but if we had a list, there might be multiple items and so we could count how many items are in that list, in this case, as I said, there's only one, so we'll just say one. Let's test it. Indeed, it is correct; there is only one. We'll save that, and we've added another assertion here. Let's also look at a couple more. So down here we've got a few that are kind of related to XML, so we won't look at those. Let's look instead at HTTP status codes. So we've got the valid HTTP status codes here. Let's add that one, and this is just a comma separated list of codes that are acceptable to get back. So we'll say 200, and let's say 201 is valid as well. We say okay, and once again it has passed. It's what we would expect. We got a 200 status code, so everything is good there. We could also look at the negative case of this. So we could look at invalid HTTP status codes. Let's add that one and say, if it was a 500, we want it to fail or a 404. If we got any of those values back, in this case we say we want this test to fail. So we'll add that, okay, and it's fine. It's valid, we have not got any of those status codes, and so everything is good. Now one last one I want to look at for this video is this SLA. So the SLA, we can add that, and it just says what's the maximum response time that this request is allowed to take. So let's leave that at 200 and hit OK, and you can see that it has failed here. So it says the response did not meet the SLA. The actual response time was 353 milliseconds instead of 200 milliseconds, and so it has checked it immediately for us and failed, letting us know there's a problem here. So in this case, let's actually just edit this. Let's say our request can take up to 500 milliseconds. So we'll say okay and all our assertions are passing at this point. So we've used a number of different asserts here, and we can see their usefulness, and we can actually do what we should be doing. We can check things in our tests.
- Creating your first project in SoapUI
- Adding request and query parameters
- Creating test suites
- Scripting with dynamic properties
- Running SoapUI from the command line or Docker