Then your “REST-Response Object Model” would be ready to verify JSON input. You can imagine, you want to use JMESPath instead of By. Here I use class to make a query for a tex “Flaskr” in the target HTML. This “Page Object” has a line static final By APP_HEADER = By.xpath('//h1') String chrome_executable_path = DriverFactory.getChromeDriverPath() Here is a Test case that uses my “Page Objects”: kazurayam/FlaskrTestInKatalonStudio/blob/master/Scripts/flaskr/TC3_Alice_and_Bob_interact/oovy import
I have ever developed a Katalon Studio project for WebUI Automation (not REST API Automation) applying Page Object Model. So a special term “Page Object Model” was invented and accepted. We need to write custom getter methods for data in a HTML document. On the other hand, an HTML document is too complex to regard an “Object” with easy accessors. Every single JSON document will be converted into a Java/Groovy object once, then you get access to it. So, I can imaging a term “REST-Response Object Model” for REST-API testing, in synonym to “Page Object Model” for WebUI test.īut I have never seen someone has ever used the term “REST-Response Object Model”. You would use different helper classes but the way you perform verifications are quite similar. If you are targetting SOAP XML, then would be perfect. Then you may want to use JMESPath to traverse the JSON content. “API Automation” means that your tests will target JSON. The term “Page Object Model” isn’t relevant to RESTful/SOAP API testing. So, you will primarily use class to look into the target HTML for data to verify. “Web UI Automation” means that your tests will target HTMLs. The term “Page Object Model” is applied only to Web UI tests. Page Object Model … for API Automation project.
0 kommentar(er)
