 REST APIs when used in conjunction with the Test Control Panel, HTTP methods, such as GET, and POST are mapped to actions on domains, environments, scenarios, and stubs. Say, if you record a request message to any URL with Integration Tester, how should the elements of the URL be interpreted? What constitutes the “operation” of this system? How can you get the integration tester to substitute values from a test data file for any given element of the URL? The answer lies in a REST schema definition in the schema view of the Architecture School. REST schemas enable you to define which elements of the URL should be parametrized and which ones should be considered as fixed values. Here is an example on how to obtain information about a stub and how to stop it using the REST API method. The attached Test Control Panel stub project includes the test that shows how to use the Test Control Panel REST API, and how to start /stop stubs. 
1. Download the attached .zip folder where you have the Integration Tester setup and import it. 2. Open the integration tester and browse to the extracted project. The project is set up to point to a local Test Control Panel installation. For example, in this scenario, the Test Control Panel active instance is https://F091512:5443/RTCP. For more information about installing Test Control Panel, refer here. Therefore, the first thing you must do is to ensure to adjust the project settings to point to your own installation of Test Control Panel. That means, you must have a TCP environment to take advantage of that project.   3. After adjusting Test Control Panel URL setting, adjust the Transport Physical Resource to match the proper host/port for your Test Control Panel machine host/port from Architecture School as shown here.  4. Open the Physical Resource, and then adjust the server/port of your Test Control Panel machine.  5. Add the SSL option (SSL tab) if needed.  6. After adjusting Test Control Panel server host/port, look at what is available in Test Factory.  Test Control Panel Stubs Status: This test will start querying all stubs on the Test Control Panel and return their information and the status based on the provided domain and environment. For instance, when you run that test and provide a domain and an environment at runtime, you can get the information of the deployed stubs and their status in the Test Control Panel.  As you can see from the above output, the href value is returned for each deployed stub. Start Stub: This test is meant to start a stub through the REST API. However, before that test works, you must adjust the Send Request Resource Path to match what the initial Test Control Panel Stub Status is returning (href value above) for the desired stub to start. For instance, if you want to start StubAdd stub, you must edit the Start stub and Send request to change the Resource path there to point to the StubAdd href.  Then, when you run that test, the stub will get started through that call. You can verify that in the Test Control Panel console or by running the Test Control Panel Stubs Status test again.   Then, when you run that test, the Receive Reply contains the href value of the running instance.  Stop stub (one running instance): Lastly, there is a Stop stub (one running instance) test that is meant to stop a stub. However, before running that test, you must edit that test to provide the href of the stub (returned with Test Control Panel Stubs Status), and the href attribute of the running stub (returned with Query stub (for running instance)) that you want to stop. In this example, the Resource Path of the Send Reply will then appear as shown here.  After making the change, when you run Stop stub (one running instance), your relevant stub is then stopped! You can then verify that your stub has been stopped either from the Test Control Panel console or by running Stubs Status again.  Rajesh Avanthi Technical Architect Rajesh Avanthi is a Technical Architect for Test Workbench suite of Products with HCL Technologies, Products and Platforms division, working with global teams delivering L2 technical assistance focused on application performance testing and service virtualization technologies. He also performs Client Advocacy role assisting focal clients with required technical support and guidance, providing solutions to various customer queries.
0 Comments
Leave a Reply. |
|||
RSS Feed