Creating a project

Creating a project is the first step to start working with IBM® DevOps Test Integrations and APIs (Test Integrations and APIs). A project contains the basic settings used by tests. You can also find different interactive guides on the Home page that provide you with information on the common tasks that you can accomplish in Test Integrations and APIs.
  • You must have closed IBM DevOps Test Virtualization Control Panel (Test Virtualization Control Panel) sessions that are running if any.
  • If Test Integrations and APIs is running and you have just completed the tasks in Creating and running a test, you probably have that project open. To create and run a stub with a WSDL file, you must create a new project. Therefore, you must close the existing project by clicking File > Close project. This action closes the project and restarts Test Integrations and APIs.

After you restart Test Integrations and APIs, you must create a new project, provide a name for your project and save it on your local drive. The following instructions are applicable for the Windows™ OS.

  1. In the startup window, select Create Project and click OK.
  2. Enter a name for the project in the Project Name field.
  3. Click Browse and select a location to save the project.

    If you do not browse and select a location, the project is saved in the default location, which is your home directory. For example, the default location is C:\Users\USER_ADMIN as shown in the following image.

    Image of the new project window.

  4. Click Finish.
The new project is created.

You must start the Add Numbers server and client. See Starting Add Numbers server and client.

Starting Add Numbers server and client

You can by using the sample WSDL documents such as the Add Numbers server and client provided along with Test Integrations and APIs, run the scripts as part of your project and test the usage of a web service hosted on your local system.

You must have created a project as described in Creating a project. Your project must be open in Test Integrations and APIs.

Test Integrations and APIs contains some example APIs. In this example, you use AddNumbers, which has a WSDL document describing the API.

If you want to model a system that does not have a WSDL definition, you can use a Swagger file (that you completed in Creating and running a test) or you can discover and record an API (that you can complete as described in Discovering, Recording, and Intercepting an HTTP proxy).

  1. In the local drive, go to <install_location>/DevOpsTestAPI/examples/addnumbers.
  2. Run the startup script.

    The Add Numbers Server window is displayed.

  3. Click Start Service.

    This action starts the Add Numbers web service on the host.

    Make a note of the Host Address and Port Number fields. You need them in the next steps.

    Image of the Add numbers Server window.

  4. In the local drive, go to <install_location>/DevOpsTestAPI/examples/addnumbersclient.
  5. Run the startup script.
    Note:
    Ensure that the host and port fields match the values that you noted earlier from the Add Numbers Server window.
  6. Click the equal sign.

    The client application sends an HTTP SOAP request to the server application, which adds the two numbers and returns the result. You can see the result on the Add Numbers Client window. This is a simple, easy-to-understand API to get you started with creating a stub.

    Image of the Add Numbers Client window.

You have successfully tested a web service hosted on your local system by using the sample WSDL.

You must import the WSDL file. See Importing the Add Numbers server’s WSDL file to model its API.

Importing the Add Numbers server’s WSDL file to model its API

You can model the WSDL's API from the Logical view in Test Integrations and APIs by using the sample WSDL provided with Test Integrations and APIs as a sub task of creating and running a stub.

You must have completed testing of the web service by using the sample WSDL file.

  1. Return to the Add Numbers Server window. Select the WSDL URL displayed in the WSDL field (http://localhost:8088/addNumbers?wsdl) and press Ctrl+C to copy it.
  2. Return to the Test Integrations and APIs window. In the toolbar, click Architecture School, and then click Logical View to view the canvas on which you will model the system.
  3. Paste the URL onto the canvas by clicking Edit > Paste. Alternatively, in the Synchronization Source window, click New. In the Select Location dialog, paste the URL into the Location field and click OK.

    Image of the Create a new Synchronization Source window.

  4. Click Next.

Test Integrations and APIs creates service components and operations on the canvas to represent the service described in the WSDL file. The options for creating tests and stubs from the service definition are also displayed. You have already used these options to create and run a test in Creating and running a test.

You must create a stub from the WSDL definition. See Creating a stub from the WSDL definition of the API.

Creating a stub from the WSDL definition of the API

You can create a stub from the WSDL definition of the API in Test Integrations and APIs by using the sample WSDL provided with Test Integrations and APIs as a sub task of creating and running a stub.

You must have completed importing the WSDL in Test Integrations and APIs.

  1. In the Generate Assets for Operations page of the Create a new Synchronization Source window, select the additionStub check box in the Create Stubs column.

    This action creates a stub for the operation based on the interface defined in the WSDL file.

    Image of the Create a new Synchronization Source window.

  2. Click Next.

    The Summary page shows the number of items created.

  3. Click Finish.

    The stub is opened in the Test Factory perspective, which is used for creating and editing tests and stubs.

    By default, the Events tab in the Stub editor is opened, which shows the events that the stub can handle. In this case, there is only one event for the addition operation. There are two sub-tabs under the Events tab labeled Input and Activity. When an event is selected, the Input tab displays the message that is expected to be received by the stub and that is handled by the selected event.

    Image showing the Events tab for the stub.

    The stub has the message structure for the SOAP message that the addNumbers addition operation expects as input. In the Activity tab, you can configure the response that is sent or other actions that are taken, when the stub receives a request that matches the data in the Input tab. Both the Activity tab and the Input tab contain the document structure, but no data yet.

    Image showing the Activity tab.

    On the Activity tab, the last two nodes in the tree called are called return (Element) (an XML element called return) and (Text) (the text content of that element).

  4. Adjacent to the (Text) node, double-click the blank cell in the Value column of the table. Enter the number 100 and press Enter. This is to check whether it is the stub that is returning the result in absence of the Add Numbers server.

    Image of the Add numbers Client window.

  5. Save the stub.

You have successfully created a stub from the WSDL definition for the API.

You must run the stub created. See Running the stub.

Running the stub

You must run the stub that you created from the imported WSDL file for the API as a sub task of creating and running a stub.
You must have created the stub from the WSDL definition for the API.
  1. In the toolbar, click Run or press F5.

    This action runs the stub in the Test Lab perspective.

    Image of the console log.

  2. Return to the Add Numbers Client window.
  3. Click the equal sign.

    The result is the same response as earlier, that is 133 because the client was not configured to use the stub yet.

You have successfully run the created stub.

You must configure the client to use the created stub. See Configuring the Add Numbers client to use the stub (virtual service).

Configuring the Add Numbers client to use the stub (virtual service)

You can configure the client to use the created stub as a virtual service.

You must have completed creating the stub and run it.

To support Test Integrations and APIs Service Virtualization, you must configure HTTP clients to use the Test Integrations and APIs HTTP/TCP Proxy. Details about the use of this proxy are in Discovering, Recording, and Intercepting an HTTP proxy.

You configure the Add Numbers client to use the Test Integrations and APIs proxy by using the standard Java proxy settings.

Note:
Other than the port number, there is nothing specific in the proxy settings of Test Integrations and APIs. Any application that sends its traffic through standard HTTP proxies can have its HTTP dependencies virtualized by using the Test Integrations and APIs HTTP/TCP Proxy.
  1. Close the Add Numbers Client window.
  2. Open the startup script located at C:\Program Files\IBM\DevOpsTestAPI/examples/addnumbersclient in a text editor.
  3. Edit the script as follows:
    • In Windows:
      1. Comment out the line %JAVA_HOME%\bin\java %NET_PROPS% %SSL_PROPS% -jar AddNumbersClient.jar by inserting @rem at the beginning.

        The edited entry appears as: @rem %JAVA_HOME%\bin\java %NET_PROPS% %SSL_PROPS% -jar AddNumbersClient.jar.

      2. Uncomment the line for connecting to a proxy as indicated by the other comments in the file. Ensure that this line includes the –Dhttp.proxyHost=localhost and -Dhttp.proxyPort=3128 arguments, which direct the application to use the proxy that is started by Test Integrations and APIs, the one that is running locally on port 3128.
    • In Linux:
      1. Comment out the line $_RUNJAVA" "${SSL[@]}" -jar "$_SCRIPTDIR/AddNumbersClient.jar.
      2. Uncomment the line for connecting to a proxy, as indicated by the other comments in the file. Ensure that this line includes the arguments -Dhttp.proxyHost=localhost and -Dhttp.proxyPort=3128, which direct the application to use the proxy that was started by Test Integrations and APIs, the one that is running locally on port 3128.
  4. Save and close the file.

You have successfully configured the Add Numbers client to use the stub.

You must call the stub. See Calling the stub.

Calling the stub

You can call the stub instead of requesting the Add Numbers server. This method is useful when you are testing the client application and if the server is unavailable or is still under development.

You must have completed configuring the Add Numbers client to use the stub.

  1. Open the Test Lab view and verify that the stub is still running.

    The status of the stub shown in the Task Monitor must read Ready. If it reads Canceled, run the stub again.

  2. Open the Add Numbers client by running the startup script located at C:\Program Files\IBM\DevOpsTestAPI/examples/addnumbersclient.

    image of the console log.

  3. Click the equal sign.

    The client returns 100 instead of the correct answer because this is the number that you configured in the stub when you created it in Creating a stub from the WSDL definition of the API.

    image of the Add numbers Client window.

    Instead of calling the Add Numbers server, the request got the response from the stub, which gives you complete control over the responses that the client receives to its requests, for example, while testing error cases.
    Important:
    In Test Integrations and APIs, stubs stop running after a specific duration. If the result returned by the Add Numbers client is 133, that is, the actual value returned by the Add Numbers server, return to Test Integrations and APIs and ensure that the stub is still running. For tests that need continuously-running stubs, you must deploy and run them in Test Virtualization.
  4. Optional: To make the Add Numbers client receive its response from the Add Numbers server again, complete the following steps:
    1. Return to the Test Integrations and APIs and ensure that Test Lab is open. If it is not, click Test Lab on the toolbar to open it.
    2. Stop the stub. Do this action by selecting the running stub in the Task Monitor table and clicking Stop icon on the toolbar.
    3. Click the equal sign on the Add Numbers client window.
      This action makes the client application receive its response from the Add Numbers server again, even though it is still configured to use the HTTP Proxy.
  • To model your system when you do not have Swagger definition or WSDL files and for more details about the HTTP/TCP Proxy, see Discovering, Recording, and Intercepting an HTTP proxy.
  • For an alternative procedure for creating a stub for the Add Numbers API, click the tile labeled Create a virtualized Web Service on the Test Integrations and APIs Home screen. This opens an internal interactive guide that walks you through creating a stub for the Add Numbers server.
  • To create additional stubs for the addition operation, perform the following steps:
    1. Open the Test Factory perspective in Test Integrations and APIs.
    2. In the tree on the left, right-click the addition operation and click New > Stubs > Stub using MEP. This action creates a stub for the operation and an event using Message Exchange Pattern of the operation that was imported from the WSDL file.
    3. To create stubs from data from your real systems rather than entering data manually, you can record the traffic in the system under test and create stubs from those recordings. For instructions on how to record traffic for creating stubs, see Discovering, Recording, and Intercepting an HTTP proxy. You can also use the recording in combination with a WSDL or Swagger definition to model the system under test. In other words, create the service components, transport resources, and operations by synchronizing with WSDL or Swagger and then record the traffic to create tests and stubs.