
Security News
vlt Launches "reproduce": A New Tool Challenging the Limits of Package Provenance
vlt's new "reproduce" tool verifies npm packages against their source code, outperforming traditional provenance adoption in the JavaScript ecosystem.
I found myself repeating a similar pattern for setting up mocks for unit tests. This package encapsulates that pattern and provides a simple, yet robust, interface.
We want to test a simple module addToDBValue.js
that adds an input value to a database value.
// addToDBValue.js
const queryDatabase = require('./database.js');
const addToDBValue = (inputValue) => {
return inputValue + queryDatabase();
}
module.exports = addToDBValue;
The only issue is that database.js
connects to an actual database.
// database.js
const queryDatabase = () => {
/* database connection and query logic */
}
module.exports = queryDatabase;
But we don't want to touch any external systems for a unit test... We can simply mock that required dependency
// test.js
const {Mock, TestSubjectMocker} = require('ez-mock');
// database mock behavior that returns 1 from query
const databaseMockReturn1 = new Mock('./database.js', () => 1);
// database mock behavior that returns 2 from query
const databaseMockReturn2 = new Mock('./database.js', () => 2);
// set the default database mock to return 1 from query
const testSubjectMocker = new TestSubjectMocker('./addToDBValue.js', databaseMockReturn1);
// instantiate foo using the default database mock
let addToDBValue = testSubjectMocker.generateSubject();
console.log(addToDBValue(1)); // 2
console.log(addToDBValue(2)); // 3
// instantiate foo with an override mock behavior
addToDBValue = testSubjectMocker.generateSubject(databaseMockReturn2);
console.log(addToDBValue(1)); // 3
console.log(addToDBValue(2)); // 4
Mock(modulePath, functionality)
modulePath: String
The module name, absolute path, or relative path to the module you wish to mock.
functionality : object/function
The functionality you wish to return when require(...)
is called.
TestSubjectMocker(modulePath, defaultMocks)
modulePath: String
The module name, absolute path, or relative path to the module you wish to test with its dependencies mocked.
defaultMocks : Mock/[Mock]
The mock behavior that will always be applied when generating a test subject.
TestSubjectMocker.generateTestSubject(overrideMocks)
defaultMocks : Mock/[Mock]
The mock behavior that overrides the default behavior for this instance of the test subject.
returns : object/function
An instance of the test subject with the mocks applied
TestSubjectMocker.clearMocks()
Clears all registered mocks (even the default mocks)
FAQs
Yet another mocking framework for Node
We found that ez-mock demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
vlt's new "reproduce" tool verifies npm packages against their source code, outperforming traditional provenance adoption in the JavaScript ecosystem.
Research
Security News
Socket researchers uncovered a malicious PyPI package exploiting Deezer’s API to enable coordinated music piracy through API abuse and C2 server control.
Research
The Socket Research Team discovered a malicious npm package, '@ton-wallet/create', stealing cryptocurrency wallet keys from developers and users in the TON ecosystem.