Debugging custom code

This example demonstrates debugging custom code by adding a breakpoint. It provides sample code to add a breakpoint. This way of debugging custom code is applicable only for a schedule.

Procedure

  1. Start HCL OneTest™ Performance and create a performance test project MyProject.
  2. Create an HTTP test, MyTest, by recording a visit to http://<hostname>:7080/.
    Note: Before accessing the URL, ensure that HCL OneTest™ Performance is running. The URL returns an HTTP 404 error, which is expected.
    A test under a loop of five iterations.
  3. Expand the first request and click the response element.
  4. In the Test Element Details section, right-click in the Content field and click Create Field Reference.
  5. Type the reference name and click OK.
  6. Click the first page, and then click Add > Custom Code.
  7. In the Arguments section of Test Element Details, click Add.
  8. Expand the data source for the search results page, select the reference name that you created in step 5, and click Select.
  9. Click Generate Code.
    A new tab with the generated code is displayed.
  10. Insert the following the code into the exec() method: 
    ITestLogManager history = tes.getTestLogManager();
if (args.length> 0) {
    if (args[0].indexOf("Invester Relations") != -1) {
        history.reportMessage("First page failed.  Bail loop!");
        tes.getLoopControl().continueLoop();
    }
}
    Important:
    • Fix the double quotation marks, if any, so they are straight and the compiler no longer gives warning.
    • To resolve complier warnings related to importing a class, press Ctrl + Shift + O.
    The code will look like this:Code for inserting breakpoint
  11. To set a breakpoint, click anywhere on the args[0].indexOf line. Move the pointer to the left-most portion of the text editor window and double-click with the pointer horizontally on the same line. A blue button is displayed in this left-most portion of the window indicating the breakpoint is set.Adding a breakpoint
  12. Save the custom code and then the test.
  13. Create a new schedule, Schtest.
    1. In Schtest, set the number of users to run to 1.
    2. Click User Group 1 and click Add > Test. Select the MyTest test and click OK.
    3. Click User Group 1 and click the Run this group on the following locations button.
    4. Click Add > Add New.
    5. In the New Location window, type the following information:
      1. In Host name, type localhost.
      2. In Name, type debuglocation.
      3. In Deployment directory, type C:\mydeploy.
      4. Click Finish.
    6. Save the schedule.
  14. In the Test Navigator, right-click debuglocation and click Open.
  15. Click the General Properties tab and click Add.
  16. In the Property name field, type RPT_VMARGS and in the Property value field, add the following values each separated by a space.
    -Xdebug
-Xnoagent
-Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
    Properties for RPT_VMARGS
  17. Save the location.
  18. Attach the debugger to the schedule execution process.
    1. Run the schedule.
      Because the schedule is using debuglocation, it will pause at the beginning to let you attach the debugger to the execute process.
    2. Click Window > Open Perspective > Other > Debug.
    3. Click Run > Debug Configurations.
    4. In the Debug Configurations window, right-click Remote Java Application and click New.
    5. Click Debug.
      A list of running threads are displayed in the Debug window and the schedule execution pauses at the debug breakpoint.
    6. If you are doing it for the first time, you might need to provide the source location to see the custom Java code. You do this by taking the following steps:
      1. Click Edit Source Lookup Path and click Add.
      2. Click Workspace Folder > OK.
      3. Now, expand MyProject, select the src folder, and click OK. The schedule run stops at the specified breakpoint. The view shows the breakpoint where the run stopped.