Forum Discussion
gsugunan
13 years agoOccasional Contributor
right, so runtime is a property in a datasink that empties to a subreport. I'm casting runtime as a string:
${=(String)testRunner.results[testRunner.results.size()-1].timeTaken}
these are the other values that will eventually be in the report
${=(String)(((long)(System.currentTimeMillis()-${runtime})%86400000)/86400000)*24}
${=(String)(((long)System.currentTimeMillis()%86400000)/86400000)*24}
${=(String)${DataSource#chi}}
when used in a single run, the dataSink step shows the correct results.
the subreport code is above, along with the code in the report referencing the subreport, I think.
btw, the dataSink is shared across the load test, and for some reason the test step is called DataSink, but is referenced as DataSinksSubReport
also, i've switched over to the nightly build from a few days ago as my primary build.
${=(String)testRunner.results[testRunner.results.size()-1].timeTaken}
these are the other values that will eventually be in the report
${=(String)(((long)(System.currentTimeMillis()-${runtime})%86400000)/86400000)*24}
${=(String)(((long)System.currentTimeMillis()%86400000)/86400000)*24}
${=(String)${DataSource#chi}}
when used in a single run, the dataSink step shows the correct results.
the subreport code is above, along with the code in the report referencing the subreport, I think.
btw, the dataSink is shared across the load test, and for some reason the test step is called DataSink, but is referenced as DataSinksSubReport
also, i've switched over to the nightly build from a few days ago as my primary build.
Related Content
- 6 months agod_bodenheimer