Feature
Many websites make ajax requests to resources which don't affect the page. E.g. Analytics. It can be useful to test when such ajax requests are made e.g.
test.page('Analytics triggers on click', async t => {
await t.click('.button');
await t.expect(networkRequests[0].url).eql('https://example.com/analytics');
await t.expect(networkRequests[0].method).eql('GET');
});
But the question is, what's a nice way of getting network requests? e.g.
t.startNetworkRecording('some name');
await t.click('.button');
t.stopNetworkRecording('some name');
const networkRequests = await t.getNetworkRequests('some name');
// or this?
t.addEventListener('onRequest', request => {});
If using WebDriver or something, you can normally instruct the browser instance to connect to a proxy, but with Testcafe, I think there is already a proxy (hammerhead) so that could be enhanced to expose all network requests to the test code.
What do you think?
Looks like it can be combined API-wise with #1271. We need to bikeshed it a bit.
Mocking is very useful indeed.
What needs to happen for this to progress? I guess you want to collect the feedback of others?
Thanks for considering it - hopefully the use case makes sense.
Yes, we need some feedback and probably time to figure out the shape of this. Anyway, current sprint is fully packed with features already, so we'll not be able to implement it until the next one.
@umaar What if we'll add handler for all proxy requests? For example:
test.onRequest(req => {
var url = req.url;
...
})
WilI it solve your problem? What request parameters will be useful for you?
By the way, I'm not just suggesting this feature for me, but also because I think it will be useful for the testcafe project 馃憤
With your example, I'm not sure if it will work.
test.page('Analytics triggers on click', async t => {
test.onRequest(req => {
var url = req.url;
t.expect(url).eql('https://example.com/analytics');
})
});
Because I don't think the test runner will wait for assertions in the onRequest callback.
The end goal is to be able to do something like:
await t.expect(networkRequests[0].url).eql('https://example.com/analytics');
Which is probably easier accomplished with this?
const networkRequests = await t.getNetworkRequests('recording-label');
Because many websites fire ajax requests without changing the UI, the only way you can test for this is by looking at the network requests. Which is the point of this feature request.
As for what data, I'd say as much as you have available e.g. all request headers, URL etc. A regular Request object would be good.
I guess I've figure out how it can be done. At first we'll implement request hooks and provide RequestLogger hook with testcafe:
import { RequestLogger } from 'testcafe';
fixture `Fixture`;
test('My test', async t => {
const logger = new RequestLogger({ logHeaders: true, logBody: false });
t.addRequestHook(logger);
// Do something...
console.log(logger.lastUrl);
console.log(logger.getRequestsFor('http://example.com/*')[0].headers);
// etc. We can exact API for logger helpers later
});
@umaar What do you think?
That looks great! Makes sense to me.
Done. For more information see the https://github.com/DevExpress/testcafe/issues/1341#issuecomment-386626497
This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.
Most helpful comment
I guess I've figure out how it can be done. At first we'll implement request hooks and provide
RequestLoggerhook with testcafe:@umaar What do you think?