@s-ui/mockmock
Advanced tools
Weekly downloads
Readme
Mocking utilities for testing.
Centralize common solutions for common mocking concerns in JavaScript.
npm install @s-ui/mockmock --save-dev
Mocks http
requests in node and XMLHttpRequest
requests in the browser.
import {HttpMocker} from '@s-ui/mockmock'
import axios from 'axios'
// Mock any requests
const mocker = new HttpMocker()
mocker
.httpMock('http://fake.api.com')
.get('/my-service')
.reply({property: 'value'}, 200)
// Make your requests
axios
.get('http://fake.api.com/my-service')
.then(response => console.log(response)) // { property: 'value' }
Also available for import
import HttpMocker from '@s-ui/mockmock/lib/http'
Since this library internally constructs the url of the original and the mocked request and then compares them, it's needed to create the mock request with the same parameter order than the original, if not, it will throw a 404.
The parameters of both petitions (original and mocked) don't have the same parameter order (err 404 thrown)
mocker
.httpMock(...)
.get('/urlToAttack')
.query({
search: 'value of the search',
working: false,
})
...
...
domain
.get('attacks_the_same_url_use_case')
.execute({
working: false,
search: 'value of the search',
})
...
...
The mocked and the original HTTP requests have to same parameter order
mocker
.httpMock(...)
.get('/urlToAttack')
.query({
search: 'value of the search',
working: true,
})
...
...
domain
.get('attacks_the_same_url_use_case')
.execute({
search: 'value of the search',
working: true,
})
...
...
It is important to clean tests before and after so you have a initial state non dependent.
Why? Sharing mutable state between components it is a bad idea.
Example:
describe('abc', () => {
beforeEach(() => {
mocker.create()
})
afterEach(() => {
mocker.restore()
})
...
it('xyz', () =>{
...
})
})
The .reply(response, statusCode, headers)
method causes the 'fake' server to respond to any request not matched by another response with the provided data.
mocker
.httpMock(...)
.get('/urlToAttack')
.query({
search: 'value of the search',
working: true,
})
.reply('{status: "ok"}', 200, {'Access-Control-Allow-Credentials': true})
...
...
const response = domain
.get('attacks_the_same_url_use_case')
.execute({
search: 'value of the search',
working: true,
})
expect(response.data.status).to.equal('ok')
If you want to test what your use_case, function, etc is doing, probably you will need to check that based on the arguments provided to the function are transformed and as an output or side effect one or various requests
are done will a certain url
, body
, or headers
.
The .requestNTH(index)
method returns the nth request
mocked by the fake server so you can assert things like:
body
of the request is the one expected.headers
of the request are the expected.url
of the request is the one expected.requests
is the correct one.mocker
.httpMock(...)
.get('/urlToAttack')
.query({
search: 'value of the search',
working: true,
})
.reply('{status: "ok"}', 200, {'Access-Control-Allow-Credentials': true})
...
...
const response = domain
.get('attacks_the_same_url_use_case')
.execute({
search: 'value of the search',
working: true,
})
const request = mock.requestNTH(0)
expect(request.body).to.be.equal('year=2030&doors=3&color=blue')
expect(request.url).to.be.equal('https://.../urlToAttack')
...
FAQs
Mocking utilities for testing.
The npm package @s-ui/mockmock receives a total of 780 weekly downloads. As such, @s-ui/mockmock popularity was classified as not popular.
We found that @s-ui/mockmock demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket installs a Github app to automatically flag issues on every pull request and report the health of your dependencies. Find out what is inside your node modules and prevent malicious activity before you update the dependencies.