For API Testing is it best to verify within the Object Repo or Test Case?

Sorry if this has been asked many times but currently I have all verifications set in the Object Repository to mimic the Postman setup that we have. However am now wondering if that is the correct approach or should the verification be moved into the Test Case itself and not just for “Send & Verify Request”?


Before I answer, first a disclaimer: I don’t use the OR for WS testing. In fact, i don’t use the OR period. That said…

Consider this: when something goes wrong and you need to investigate why, use the system that brings the error or erroneous code or problem area to your attention as quickly as possible. If you think digging through the OR is efficient, then by all means, put it there. If you think reading your code right where the error/problem occurs is a better place to put stuff, do it that way.

Said another way, if you find yourself saying this a lot, “where the hell is that stuff…?” then change your approach. Use a more efficient (for you) system.

Make sense?

Confession: (If you hadn’t guessed already) I find the OR to be a classic example of “form over function”.


Hello Manish,

I think this question does not have any correct answer. It really depends on your preferences. Maybe I would slightly prefer doing verification in a test case, just because you can easily compare your API response with other parts of your test. But if the request is isolated and not dependent on any other part of the test, it is 100% fine to use Verification in Object Repo.

1 Like

I agree with both @Russ_Thomas and @Marek_Melocik, it really depends on the overall design of your project. However, I would like to add a couple of other things to consider:

1.) Most importantly, according to your post, this is a debate over storing your locators (you’ve called them “verifications”) in the Object Repository vs storing them in the Test Case. I firmly believe that you should not store any locators that you intend to reuse in a Test Case, hopefully for reasons that are obvious (you won’t be able to reuse them).

That being said, you could change the debate to Object Repository vs storing in a Custom Keyword. If you exploit the page object model as I do, you could store your locator (xpath, css, etc.) as a simple String in the page object that represents the section of the application you are trying to interact with, and avoid the Object Repository entirely.

2.) One of the benefits of using the Object Repository is that you can make use of Katalon’s WebUI API more easily, as most of the methods there take a Test Object as an argument.

3.) Related to #3 is the fact that you can take advantage of the WebUI’s timeout argument if you use the Object Repository. If you decide to store the locators yourself somewhere else, and it comes time to actually find the element in the DOM, you are responsible for properly waiting for the page to be ready for that.

Just some food for thought :slight_smile:

Edit: Just realized I may be talking about something entirely different than “verifications” (doh :persevere:), but I think these points are still relevant…


Thanks for the replies everyone. I probably should have clarified with some examples but here is an item in my Object Repository with verification.


And from the Test Case.

I was thinking about the original question 2 weeks ago however after yesterdays Webinar, with an example of verification within the test case, it got me wondering again.

For my case … at the beginning I was tempted to organize my project ‘Psotman style’ … but I find out Katalon gave me more options, so why not to use them? So this is how I am organizing my API projects:

  • in Object Repository I have only generic, parametrized requests, usually one for each http verb. For some of them I have duplicates, because there are cases when I need to pass a token for authorization, sometime not.

  • i’m using verification snippets only for quick-check if a call is right formatted (using variables feature) but the actual check is always done in the test case. It is more easy like this to trace what went wrong if a call fail, since I am abusing comment’s and logers.

I use this structure because it gives me more flexibility.
Sometime I check only the response code, sometime I have to check also the response content - json schema, specific key values, sometime I have to extract also values to be reused by another test case etc. Using verification snippets for validation will lead to a lot of duplicated object requests.

One practical case:
I have a call which, using some values for given parameters, can return 200, or 204 for different values.
If I put the verification in the object request, I have to use duplicated calls, or to use a (200,204) validation, which is not accurate in my opinion.