How to test nodejs chaincode using ChainCodeMockStub - node.js

I am trying to test nodejs chaincode without deploying it to a hyperledger fabic network. There is a popular nodejs library called #theledger/fabric-mock-stub. Below is my unit test
const Chaincode = require('./index.js');
// import { ChaincodeMockStub, Transform } from "#theledger/fabric-mock-stub";
const ChaincodeMockStub = require("#theledger/fabric-mock-stub")
// You always need your chaincode so it knows which chaincode to invoke on
const chaincode = new Chaincode();
describe('Test MyChaincode', () => {
it("Should init without issues", async () => {
const mockStub = new ChaincodeMockStub("MyMockStub", chaincode);
const response = await mockStub.mockInit("tx1", []);
expect(response.status).to.eql(200)
});
});
When this test is run the following error is received
2019-04-08T18:34:55.530Z ERROR [lib/chaincode.js] uncaughtException: Missing required argument peer.address
Does anyone know how to use this testing library? https://github.com/wearetheledger/fabric-mock-stub
Any help would be greatly appreciated thanks.

I had the same issue and what I noticed is that at the bottom of my chaincode js file I had
shim.start(new Chaincode())
If you move this line to another file or comment it out before doing tests, tests should work just fine.

Related

How to delete repo.lock from IPFS in Next.js (or how to get rid of the error)

I am trying to build a Next.js web application in which the browser is an IPFS node. When I am to make the IPFS node, I get this error:
This is the code where I make the IPFS instance:
import * as IPFSCORE from 'ipfs-core';
const IPFS = (() => {
let IPFSInstance = undefined;
const createInstance = async () => {
return await IPFSCORE.create();
}
return {
getInstance: async () => {
if (!IPFSInstance) IPFSInstance = await createInstance();
return IPFSInstance;
}
}
})();
export default IPFS;
Here is a little more background: I experimented with IPFS on Node.js first. There I got this repo.lock error when I saved my app and then it refreshed (with nodemon). So I thought that making a singleton kind of code in order to create the IPFS instance only once will do the job, and it did. But at the same time, when working locally with Node.js, the repo.lock file was saved on my machine, and when I got the error (prior to making the singleton), I just deleted the file. When I switched to Next.js, I can't find the repo.lock file, like it's not on my machine. Where is the file? Or how can I get rid of this error? Or should I take another approach in order to create the IPFS instance only once?

Jest initialize and shared objects once per test suite and across test cases

I want to use shared resources between jest test suites. I read in the internet and found that this could be the solution. But the setup is invoked per each test file.
I have two test files links.test.js and 'subscritpions.test.js'. I usually call them with one command jest and that all.
The problem is that the setup function of my custom environment custom-environment.js:
const NodeEnvironment = require('jest-environment-node');
const MySql = require('../../lib/databases/myslq/db');
class CustomEnvironment extends NodeEnvironment {
constructor(config) {
super(config)
}
async setup() {
await super.setup();
console.log(`Global Setup !!!!!!!!!`);
this.global.gObject = "I am global object"
this.global.liveUsers = await new MySql("Live Users");
this.global.stageUsers = await new MySql("Stage Users");
}
async teardown() {
console.log(`Global terdown !!!!!!!!!`);
await super.teardown();
this.global.gObject = "I am destroyed";
this.global.liveUsers.closeConnection();
this.global.stageUsers.closeConnection();
}
runScript(script) {
return super.runScript(script)
}
}
module.exports = CustomEnvironment;
is called twice for each test:
Global Setup !!!!!!!!!
Global Setup !!!!!!!!!
ERROR>>> Error: listen EADDRINUSE: address already in use 127.0.0.1:3306
So it tries to establish second connection to the same port - while I could simply use the existing connection.
The way it works seems to me makes no difference from defining
beforeAll(async () => {
});
afterAll(() => {
});
hooks.
So to wrap up, the question is: Using jest command (thus running all test suits), how can I invoke setup function once for all test and share global objects across them?
setup and teardown are indeed executed for each test suite, similarly to top-level beforeAll and afterAll.
Test suites run in separate processes. Test environment is initialized for each test suite, e.g. jsdom environment provides fake DOM instance for each suite and cannot be cross-contaminated between them.
As the documentation states,
Note: TestEnvironment is sandboxed. Each test suite will trigger setup/teardown in their own TestEnvironment.
The environment isn't suitable for global setup and teardown. globalSetup and globalTeardown should be used for that. They are appropriate for setting up and shutting down server instances, this is what documentation example shows:
// setup.js
module.exports = async () => {
// ...
// Set reference to mongod in order to close the server during teardown.
global.__MONGOD__ = mongod;
};
// teardown.js
module.exports = async function () {
await global.__MONGOD__.stop();
};
Since this happens in parent process, __MONGOD__ is unavailable in test suites.

Is it okay to make API requests to set up tests in Cypress when testing serverless applications?

I'm writing a serverless React app using AWS Amplify. I do my E2E tests using Cypress.
Before each test, I log the user in via the AWS Amplify CLI. Afterwards, I clear all data on the development server and create some new data using fixtures. This way I always have controlled state for each test (see code below).
My question is: Is this a good practice? Or is it bad to make that many requests against the server in before each test? If it is bad, how would you do that if you do not have direct access to the server (again serverless) to run commands like cy.exec('npm run db:reset && npm run db:seed')? Cypress does warn me in the console about the use of promises:
Cypress detected that you returned a promise in a test, but also invoked one or more cy commands inside of that promise.
Here is the code I use:
import API, { graphqlOperation } from '#aws-amplify/api';
import Auth from '#aws-amplify/auth';
import Amplify from 'aws-amplify';
import * as R from 'ramda';
import config from '../../src/aws-exports';
import { contacts } from '../../src/contacts/fixtures';
import { replaceEmptyStringsWithNull } from '../../src/contacts/helpers';
import {
createContact as addMutation,
deleteContact as deleteMutation
} from '../../src/graphql/mutations';
import { listContacts } from '../../src/graphql/queries';
Amplify.configure(config);
const deleteContact = input =>
API.graphql(graphqlOperation(deleteMutation, { input }));
const createContact = input =>
API.graphql(graphqlOperation(addMutation, { input }));
describe('Contactlist', () => {
beforeEach(async () => {
await Auth.signIn(Cypress.env('email'), Cypress.env('password'));
const allContacts = await API.graphql(graphqlOperation(listContacts));
await Promise.all(
R.map(
R.pipe(
R.prop('id'),
id => ({ id }),
deleteContact
)
)(allContacts.data.listContacts.items)
);
await Promise.all(
R.map(
R.pipe(
R.dissoc('id'),
replaceEmptyStringsWithNull,
createContact
)
)(contacts)
);
});
// ... my tests
It would be exactly the way I would perform the test. I love to start with a fully controlled state, even if that means having multiple API-calls as a before()

Error:"Failed to get the current sub/segment from the context" when use AWS X-ray in Lambda with node.js

I am trying to use implement the AWS X-ray into my current project (using Node.js and Serverless framework). I am trying to wire the X-ray to one of my lambda function, I got the problem of
Error: Failed to get the current sub/segment from the context.
at Object.contextMissingRuntimeError [as contextMissing] (/.../node_modules/aws-xray-sdk-core/lib/context_utils.js:21:15)
at Object.getSegment (/.../node_modules/aws-xray-sdk-core/lib/context_utils.js:92:45)
at Object.resolveSegment (/.../node_modules/aws-xray-sdk-core/lib/context_utils.js:73:19).....
code below:
import { DynamoDB } from "aws-sdk";
import AWSXRay from 'aws-xray-sdk';
export const handler = async (event, context, callback) => {
const dynamo = new DynamoDB.DocumentClient({
service: new DynamoDB({ region })
});
AWSXRay.captureAWSClient(dynamo.service);
try {
// call dynamoDB function
} catch(err) {
//...
}
}
for this problem, I use the solution from
https://forums.aws.amazon.com/thread.jspa?messageID=821510&#821510
the other solution I tried is from https://forums.aws.amazon.com/thread.jspa?messageID=829923&#829923
code is like
import AWSXRay from 'aws-xray-sdk';
const AWS = AWSXRay.captureAWS(require('aws-sdk'));
export const handler = async (event, context, callback) => {
const dynamo = new AWS.DynamoDB.DocumentClient({region});
//....
}
Still not working...
Appreciated to the help of any kind.
As you mention, that happened because you're running locally (using serverless-offline plugin) and the serverless-offline plugin doesn't provide a valid XRAY context.
One possible way to pass this error and still be able to call your function locally is setting AWS_XRAY_CONTEXT_MISSING environment variable to LOG_ERROR instead of RUNTIME_ERROR (default).
Something like:
serverless invoke local -f functionName -e AWS_XRAY_CONTEXT_MISSING=LOG_ERROR
I didn't test this using serverless framework but it worked when the same error occurred calling an amplify function locally:
amplify function invoke <function-name>
I encountered this error also. To fix it, I disabled XRay when running locally. XRay isn't needed when running locally because I can just set up debug log statements at that time.
This is what the code would look like
let AWS = require('aws-sdk');
if (!process.env.IS_OFFLINE) {
const AWSXRay = require('aws-xray-sdk');
AWS = AWSXRay.captureAWS(require('aws-sdk'));
}
If you don't like this approach, you can set up a contextStrategy to not error out when the context is missing.
Link here
AWSXRay.setContextMissingStrategy("LOG_ERROR");
If you don't want the error clogging up your output you can add a helper that ignores only that error.
// Removes noisy Error: Failed to get the current sub/segment from the context due to Xray
export async function disableXrayError() {
console.error = jest.fn((err) => {
if (err.message.includes("Failed to get the current sub/segment from the context")) {
return;
} else {
console.error(err);
}
});
}

Is there a jest config that will fail tests on console.warn?

How do I configure jest tests to fail on warnings?
console.warn('stuff');
// fail test
You can use this simple override :
let error = console.error
console.error = function (message) {
error.apply(console, arguments) // keep default behaviour
throw (message instanceof Error ? message : new Error(message))
}
You can make it available across all tests using Jest setupFiles.
In package.json :
"jest": {
"setupFiles": [
"./tests/jest.overrides.js"
]
}
Then put the snippet into jest.overrides.js
For those using create-react-app, not wanting to run npm run eject, you can add the following code to ./src/setupTests.js:
global.console.warn = (message) => {
throw message
}
global.console.error = (message) => {
throw message
}
Now, jest will fail when messages are passed to console.warn or console.error.
create-react-app Docs - Initializing Test Environment
I implemented this recently using jest.spyOn introduced in v19.0.0 to mock the warn method of console (which is accesses via the global context / object).
Can then expect that the mocked warn was not called, as shown below.
describe('A function that does something', () => {
it('Should not trigger a warning', () => {
var warn = jest.spyOn(global.console, 'warn');
// Do something that may trigger warning via `console.warn`
doSomething();
// ... i.e.
console.warn('stuff');
// Check that warn was not called (fail on warning)
expect(warn).not.toHaveBeenCalled();
// Cleanup
warn.mockReset();
warn.mockRestore();
});
});
There is a useful npm package that helps you to achieve that: jest-fail-on-console
It's easily configurable.
Install:
npm i -D jest-fail-on-console
Configure:
In a file used in the setupFilesAfterEnv option of Jest, add this code:
import failOnConsole from 'jest-fail-on-console'
failOnConsole()
// or with options:
failOnConsole({ shouldFailOnWarn: false })
I decided to post a full example based on user1823021 answer
describe('#perform', () => {
var api
// the global.fetch is set to jest.fn() object globally
global.fetch = jest.fn()
var warn = jest.spyOn(global.console, 'warn');
beforeEach(function() {
// before every test, all mocks need to be resetted
api = new Api()
global.fetch.mockReset()
warn.mockReset()
});
it('triggers an console.warn if fetch fails', function() {
// In this test fetch mock throws an error
global.fetch.mockImplementationOnce(() => {
throw 'error triggered'
})
// I run the test
api.perform()
// I verify that the warn spy has been triggered
expect(warn).toHaveBeenCalledTimes(1);
expect(warn).toBeCalledWith("api call failed with error: ", "error triggered")
});
it('calls fetch function', function() {
// I create 2 more mock objects to verify the fetch parameters
const url = jest.fn()
const config = jest.fn()
api.url = url
api.config = config
// I run the test
api.perform()
// I verify that fetch has been called with url and config mocks
expect(global.fetch).toHaveBeenCalledTimes(1)
expect(global.fetch).toBeCalledWith(url, config)
expect(warn).toHaveBeenCalledTimes(0)
});
})
the #perform method I am testing
class Api {
constructor(auth) {
this._credentials = auth
}
perform = async () => {
try {
return await fetch(this.url, this.config)
} catch(error) {
console.warn('api call failed with error: ', error)
}
}
}
You can set the environment variable CI=true before running jest which will cause it to fail tests on warnings in addition to errors.
Example which runs all test files in the test folder:
CI=true jest ./test
Automated CI/CD pipelines such as Github Actions set CI to true by default, which can be one reason why a unit test will pass on your local machine when warnings are thrown, but fail in the pipeline.
(Here is the Github Actions documentation on default environment variables: https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables)

Resources