Gathering detailed insights and metrics for wdio-intercept-service
Gathering detailed insights and metrics for wdio-intercept-service
Gathering detailed insights and metrics for wdio-intercept-service
Gathering detailed insights and metrics for wdio-intercept-service
@wdio/devtools-service
A WebdriverIO service that allows you to run Chrome DevTools commands in your tests
wdio-chromedriver-service
WebdriverIO service to start & stop ChromeDriver
@wdio/local-runner
A WebdriverIO runner to run tests locally
@wdio/utils
A WDIO helper utility to provide several utility functions used across the project.
npm install wdio-intercept-service
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
105 Stars
764 Commits
33 Forks
12 Watching
80 Branches
29 Contributors
Updated on 25 Nov 2024
JavaScript (76.25%)
HTML (23.75%)
Cumulative downloads
Total Downloads
Last day
-11.4%
13,074
Compared to previous day
Last week
-9.2%
84,112
Compared to previous week
Last month
-1%
363,803
Compared to previous month
Last year
99.6%
4,241,930
Compared to previous year
🕸 Capture and assert HTTP ajax calls in webdriver.io
This is a plugin for webdriver.io. If you don't know it yet, check it out, it's pretty cool.
Although selenium and webdriver are used for e2e and especially UI testing, you might want to assess HTTP requests done by your client code (e.g. when you don't have immediate UI feedback, like in metrics or tracking calls). With wdio-intercept-service you can intercept ajax HTTP calls initiated by some user action (e.g. a button press, etc.) and make assertions about the request and corresponding responses later.
There's one catch though: you can't intercept HTTP calls that are initiated on page load (like in most SPAs), as it requires some setup work that can only be done after the page is loaded (due to limitations in selenium). That means you can just capture requests that were initiated inside a test. If you're fine with that, this plugin might be for you, so read on.
Heads up! If you're still using webdriver.io v4, please use the v2.x branch of this plugin!
1npm install wdio-intercept-service -D
It should be as easy as adding wdio-intercept-service to your wdio.conf.js
:
1exports.config = { 2 // ... 3 services: ['intercept'] 4 // ... 5};
and you're all set.
When using WebdriverIO Standalone, the before
and beforeTest
/ beforeScenario
functions need to be called manually.
1import { remote } from 'webdriverio'; 2import WebdriverAjax from 'wdio-intercept-service' 3 4const WDIO_OPTIONS = { 5 port: 9515, 6 path: '/', 7 capabilities: { 8 browserName: 'chrome' 9 }, 10} 11 12let browser; 13const interceptServiceLauncher = WebdriverAjax(); 14 15beforeAll(async () => { 16 browser = await remote(WDIO_OPTIONS) 17 interceptServiceLauncher.before(null, null, browser) 18}) 19 20beforeEach(async () => { 21 interceptServiceLauncher.beforeTest() 22}) 23 24afterAll(async () => { 25 await client.deleteSession() 26}); 27 28describe('', async () => { 29 ... // See example usage 30});
Once initialized, some related functions are added to your browser command chain (see API).
Example usage:
1browser.url('http://foo.bar'); 2browser.setupInterceptor(); // capture ajax calls 3browser.expectRequest('GET', '/api/foo', 200); // expect GET request to /api/foo with 200 statusCode 4browser.expectRequest('POST', '/api/foo', 400); // expect POST request to /api/foo with 400 statusCode 5browser.expectRequest('GET', /\/api\/foo/, 200); // can validate a URL with regex, too 6browser.click('#button'); // button that initiates ajax request 7browser.pause(1000); // maybe wait a bit until request is finished 8browser.assertRequests(); // validate the requests
Get details about requests:
1browser.url('http://foo.bar') 2browser.setupInterceptor(); 3browser.click('#button') 4browser.pause(1000); 5 6var request = browser.getRequest(0); 7assert.equal(request.method, 'GET'); 8assert.equal(request.response.headers['content-length'], '42');
It should work with somewhat newer versions of all browsers. Please report an issue if it doesn't seem to work with yours.
Consult the TypeScript declaration file for the the full syntax of the custom commands added to the WebdriverIO browser object. In general, any method that takes an "options" object as a parameter can be called without that parameter to obtain the default behavior. These "optional options" objects are followed by ?: = {}
and the default values inferred are described for each method.
This library offers a small amount of configuration when issuing commands. Configuration options that are used by multiple methods are described here (see each method definition to determine specific support).
orderBy
('START' | 'END'
): This option controls the ordering of requests captured by the interceptor, when returned to your test. For backwards compatibility with existing versions of this library, the default ordering is 'END'
, which corresponds to when the request was completed. If you set the orderBy
option to 'START'
, then the requests will be ordered according to the time that they were started.includePending
(boolean
): This option controls whether not-yet-completed requests will be returned. For backwards compatibility with existing versions of this library, the default value is false
, and only completed requests will be returned.Captures ajax calls in the browser. You always have to call the setup function in order to assess requests later.
Prevents further capture of ajax calls in the browser. All captured request information is removed. Most users will not need to disable the interceptor, but if a test is particularly long-running or exceeds the session storage capacity, then disabling the interceptor can be helpful.
Excludes requests from certain urls from being recorded. It takes an array of strings or regular expressions. Before writing to storage, tests the url of the request against each string or regex. If it does, the request is not written to storage. Like disableInterceptor, this can be helpful if running into problems with session storage exceeding capacity.
Make expectations about the ajax requests that are going to be initiated during the test. Can (and should) be chained. The order of the expectations should map to the order of the requests being made.
method
(String
): http method that is expected. Can be anything xhr.open()
accepts as first argument.url
(String
|RegExp
): exact URL that is called in the request as a string or RegExp to matchstatusCode
(Number
): expected status code of the responseHelper method. Returns all the expectations you've made up until that point
Helper method. Resets all the expectations you've made up until that point
Call this method when all expected ajax requests are finished. It compares the expectations to the actual requests made and asserts the following:
{ orderBy: 'END' }
, i.e. when the requests were completed, to be consistent with the behavior of v4.1.10 and earlier. When the orderBy
option is set to 'START'
, the requests will be ordered by when they were initiated by the page.Similar to browser.assertRequests
, but validates only the requests you specify in your expectRequest
directives, without having to map out all the network requests that might happen around that. If inOrder
option is true
(default), the requests are expected to be found in the same order as they were setup with expectRequest
.
To make more sophisticated assertions about a specific request you can get details for a specific request. You have to provide the 0-based index of the request you want to access, in the order the requests were completed (default), or initiated (by passing the orderBy: 'START'
option).
index
(number
): number of the request you want to accessoptions
(object
): Configuration optionsoptions.includePending
(boolean
): Whether not-yet-completed requests should be returned. By default, this is false, to match the behavior of the library in v4.1.10 and earlier.options.orderBy
('START' | 'END'
): How the requests should be ordered. By default, this is 'END'
, to match the behavior of the library in v4.1.10 and earlier. If 'START'
, the requests will be ordered by the time of initiation, rather than the time of request completion. (Since a pending request has not yet completed, when ordering by 'END'
all pending requests will come after all completed requests.)Returns request
object:
request.url
: requested URLrequest.method
: used HTTP methodrequest.body
: payload/body data used in requestrequest.headers
: request http headers as JS objectrequest.pending
: boolean flag for whether this request is complete (i.e. has a response
property), or in-flight.request.response
: a JS object that is only present if the request is completed (i.e. request.pending === false
), containing data about the response.request.response?.headers
: response http headers as JS objectrequest.response?.body
: response body (will be parsed as JSON if possible)request.response?.statusCode
: response status codeA note on request.body
: wdio-intercept-service will try to parse the request body as follows:
'value'
)JSON.parse()
(({ key: value })
){ key: [value1, value2, ...] }
JSON.stringify()
on your data. Good luck!For the fetch
API, we only support string and JSON data!
Get all captured requests as an array, supporting the same optional options as getRequest
.
Returns array of request
objects.
A utility method that checks whether any HTTP requests are still pending. Can be used by tests to ensure all requests have completed within a reasonable amount of time, or to verify that a call to getRequests()
or assertRequests()
will include all of the desired HTTP requests.
Returns boolean
This plugin provides its own TS types. Just point your tsconfig to the type extensions like mentioned here:
"compilerOptions": {
// ..
"types": ["node", "webdriverio", "wdio-intercept-service"]
},
Recent versions of Chrome and Firefox are required to run the tests locally. You may need to update the chromedriver
and geckodriver
dependencies to match the version installed on your system.
1npm test
I'm happy for every contribution. Just open an issue or directly file a PR.
Please note that this interceptor library is written to work with legacy browsers such as Internet Explorer. As such, any code used in lib/interceptor.js
must at least be parseable by Internet Explorer's JavaScript runtime.
MIT
No vulnerabilities found.
Reason
21 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
4 existing vulnerabilities detected
Details
Reason
dependency not pinned by hash detected -- score normalized to 2
Details
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More