Implement a response time calculation to test API response latency.
See original GitHub issueIs your feature request related to a problem? Please describe. I would like to test my API endpoints latency by adding a test that measures it. Currently, Postman uses responseTime:
pm.test("Response time is less than 1000ms", function () {
pm.expect(pm.response.responseTime).to.be.below(1000);
});
Describe the solution you’d like After talking to @reynolek - the solution would be seem to be as follows:
“It would need a variable added to the request config (a start time), and then once the request has returned, calculate the time between return and start time in milliseconds, and include that in the data being returned by send.”
Additional context Looking to move away from Postman, so hoping to have this added. Thank you!
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Response Time Testing – How to Measure for API? - Guru99
Step 1) Method of calculating metrics gathered by each API response time test tool; Step 2) Tools Simulate the load and capture speed...
Read more >Comparison between API's Latency Rate vs Response Rate
You can use the test tool to measure response times by inserting critical business processes into the start and finish transactions. For the ......
Read more >API Response Time, Explained in 1000 Words or Less
As you can see from the diagram, response time is approximately the sum of latency and server processing time. What is a good...
Read more >5 Types of Response Time Metrics and How To Measure It
Response time testing is a measurement of the amount of time that passes between a user's request and a response from the server,...
Read more >How to Performance test your API the right way and improve ...
Figure 1 and 2 shows the response time for a single call made to our API. Response time with data = 4 *...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks a lot for the detailed overview @develohpanda! I will try creating a PR for this today itself.
Hi @amaaniqbal!
When writing a unit test, the
insomnia
class instance for Mocha is set up here: https://github.com/Kong/insomnia/blob/5f4c19da35e90ffa2f3ae27e9b309ee48f9d4e16/packages/insomnia-testing/src/run/run.ts#L30-L30This class will use a
sendRequest
callback if it exists in the options sent to the constructor, and use axios as a fallback. https://github.com/Kong/insomnia/blob/5f4c19da35e90ffa2f3ae27e9b309ee48f9d4e16/packages/insomnia-testing/src/run/insomnia.ts#L78-L80That options object in the constructor of
Insomnia
, is sent either frominsomnia-app
orinsomnia-inso
: https://github.com/Kong/insomnia/blob/6e073c8a38f4b9c783786e3a2c149a10c7d38dec/packages/insomnia-app/app/ui/components/wrapper-unit-test.tsx#L279-L283https://github.com/Kong/insomnia/blob/5f4c19da35e90ffa2f3ae27e9b309ee48f9d4e16/packages/insomnia-inso/src/commands/run-tests.ts#L97-L103
This means, because all of the entry points in the app and the CLI actually provide the
sendRequest
callback, axios is never consumed. (As an aside, we can likely remove axios, it was a remnant of the initial build PoC)Finishing off the links,
sendRequest
is defined here, exposing Insomnia’s networking logic as a standalone library: https://github.com/Kong/insomnia/blob/6e073c8a38f4b9c783786e3a2c149a10c7d38dec/packages/insomnia-app/app/common/send-request.ts#L41-L62The response returned from that
sendAndTransform
function is what is available to you in unit tests.It appears that the elapsed time for a request is already available on the
res
response object insendAndTransform
! So if you add it here, in theory you should have the elapsed time available for you in unit testsIn terms of precision, I would stick with returning the time in ms with no decimal places, since working in milliseconds is fairly standard in JS.