I'm building a single page web application (SPA) with server side rendering (SSR).
We have a node backend API which is called both from the node server during SSR and from the browser after initial rendering.
I want to write e2e tests that configures API responses (like with nock) and work both with browser calls and SSR server calls. some pseudo-code :
it('loads some page (SSR mode)', () => {
mockAPI.response('/some-path', {text: "some text"}); // here i configure the mock server response
browser.load('/some-other-page'); // hit server for SSR response
expect(myPage).toContain('some text');
})
it('loads some other page (SPA mode)', () => {
mockAPI.response('/some-path', {text: "some other text"}); // here i configure another response for the same call
browser.click('#some-link'); // loads another page client side only : no SSR here
expect(myPage).toContain('some other text');
})
Currently Cypress allows me to mock fetch on the browser but not on the server.
Is there anything to achieve that ?
Preferably with node libs.
MockTTP can do that. Excerpt from the doc :
const superagent = require("superagent");
const mockServer = require("mockttp").getLocal();
describe("Mockttp", () => {
// Start your server
beforeEach(() => mockServer.start(8080));
afterEach(() => mockServer.stop());
it("lets you mock requests, and assert on the results", () =>
// Mock your endpoints
mockServer.get("/mocked-path").thenReply(200, "A mocked response")
.then(() => {
// Make a request
return superagent.get("http://localhost:8080/mocked-path");
}).then(() => {
// Assert on the results
expect(response.text).to.equal("A mocked response");
});
);
});
We used a particularly ugly solution, that breaks the speed of cypress, but we needed that in order to mock/fake socket calls.
You can make a real simple express server that starts before running your tests. This 'real fake server' will be able to respond what you need.
Here are the specs of our:
POST on / with method, path and {data} in body params in order to setup a route
GET/POST/PUT/DELETE on /path responds {data}
DELETE on / clear all the routes
Let's consider your 'real fake server' run on 0.0.0.0:3000; you'll do:
beforeEach() {
cy.request('DELETE', 'http://0.0.0.0:3000/');
}
it('loads some page (SSR mode)', () => {
cy.request('POST', 'http://0.0.0.0:3000/', {
method: 'GET',
path: '/some-path',
data: {text: "some other text"}
}) // here i tell my 'real fake server' to
// respond {text: "some other text"} when it receives GET request on /some-path
browser.load('/some-other-page'); // hit server for SSR response
expect(myPage).toContain('some text');
})
it('loads some other page (SPA mode)', () => {
cy.request('POST', 'http://0.0.0.0:3000/', {
method: 'GET',
path: '/some-path',
data: {text: "some other text"}
}); // here i configure another response for the same call
browser.click('#some-link'); // loads another page client side only : no SSR here
expect(myPage).toContain('some other text');
})
Important : the resquests need to be in localhost. You won't be able to stub something external. (Hence, make an env var in order to request localhost:xxxx instead of google.com when you test your app)
You won't be able to control the 'real fake server' otherwise than this cy.request because your tests scripts run in the browser (correct me if I'm wrong) and the browser can't run an express server.
Related
I'm trying to test my fullstack angular-nestjs-application with cypress e2e tests.
Server calls from within angular to not reach my backend running on localhost:443 (I tested it with 0.0.0.0, 127.0.0.1 like some other answers requested - without success.
I also did try to add a local proxy on my machine like some other posts suggested - again without any success).
On the other hand: Requests sent by cy.request('http://localhost:443/...' do actually reach my backend. I am able to send the request in beforeEach, save the response, intercept the real request and feed the saved response data to it.
cy.login() does a login call to build a valid session for my backend.
describe('test', () => {
let data: any;
beforeEach(() => {
cy.login();
cy.request('http://localhost:443/load').then(response => {
data = response;
console.log('BeforeEach Response: ', data);
});
});
it('load data', () => {
cy.visit('/');
});
});
But the following line in beforeEach does work:
cy.request('http://localhost:443/load').then(response => {
data = response;
console.log('BeforeEach Response: ', data);
});
So the following test does work completely:
describe('test', () => {
let data: any;
beforeEach(() => {
cy.login();
cy.request('http://localhost:443/load').then(response => {
data = response;
console.log('BeforeEach Response: ', data);
});
});
it('load data', () => {
cy.intercept('/load', data);
cy.visit('/');
});
});
So what am i missing to successfully test my application with real server requests - without sending the same request by hand and stubing the real one?
I assume your baseUrl in cypress.json is not localhost:443. If that's the case, then for chrome-based browsers you can set chromeWebSecurity to false. See https://docs.cypress.io/guides/guides/web-security#Set-chromeWebSecurity-to-false.
If that doesn't help or you have to test with firefox then you have to put your app and all required backend-services behind a proxy, so that it looks like every request is served by the proxy.
If you have Angular in dev-mode then you already have a proxy and you can configure your backend services via proxy.conf.json. See https://angular.io/guide/build#proxying-to-a-backend-server
I'm trying to do some integration tests for my api in express.
My API's structure is something like:
app -> routes -> controllers -> services
Because I already have unit tests, my idea is only test that all that components are connected in the correct way.
So my idea was created an stub with Sinon for the service, and only check the responses of the controller with supertest.
When I run a single test everything is ok. The problem is when I run more than one unit test for different controllers, the stub doesn't work in the second run.
I think it's because the app is already saved in cache as a module, so sinon can't stub the service.
Some examples of my code:
controller.js
const httpStatus = require('http-status');
const { service } = require('../services/croupier');
/**
* Execute lambda tasks for candidates
* #public
*/
exports.task = async (req, res, next) => {
try {
const result = await service({
body: req.body,
authorizer: req.authorizer
});
console.log('res', result);
res.status(httpStatus.OK).json(result);
} catch (error) {
next(error);
}
};
foo.integration.test.js
const request = require('supertest');
const httpStatus = require('http-status');
const sinon = require('sinon');
const mongoose = require('../../../database');
const deleteModule = module => delete require.cache[require.resolve(module)];
const requireUncached = module => {
deleteModule(module);
return require(module);
};
describe('Foo - Integration Test', async () => {
describe('POST /v1/foo', () => {
const fooService = require('../../services/foo');
const stub = sinon.stub(fooService, 'service');
let db;
before(async () => {
db = await mongoose.connect();
});
afterEach(async () => {
sinon.restore();
});
after(async () => {
await db.close();
});
it('the api should response successfully', async () => {
stub.returns({});
const payload = { task: 'task', payload: [{ pathParameters: {}, body: {} }] };
const app = requireUncached('../../../app');
await request(app)
.post('/api/foo')
.send(payload)
.expect(httpStatus.OK);
});
it('the api should response with an error', async () => {
stub.throwsException();
const payload = { task: 'task', payload: [{ pathParameters: {}, body: {} }] };
const app = requireUncached('../../../app');
await request(app)
.post('/api/foo')
.send(payload)
.expect(httpStatus.INTERNAL_SERVER_ERROR);
});
});
});
The other integration tests have the same structure. I've also tried using proxyquire but didn't work.
Also I tried deleting cache of de app.js with any success.
Any ideas?
Context: integration test.
I agree with your idea: "test that all that components are connected in the correct way". Then what you need is spy, not stub. When there is a case / condition, you need to setup preconfigured/dummy data (up mongodb with specific data), turn on HTTP server, call HTTP request with specific data (post / get with specific query), and check the HTTP response for correct status, etc. The spy needed to check/validate/verify whether your service get called with correct parameter and response with correct result. This test validate you have correctly configured route - controller to a service for specific HTTP request.
You must have question: How to test negative scenario? For example: 404, 500. Then you need to know which specific scenario do what, which result negative condition. For example: if request come with unknown ID query, then response will be 404. Or if express not connected to database, then response will be 500. You need to know the real scenario, and again provide the require setup to produce the negative response.
For problem: "When I run a single test everything is ok. The problem is when I run more than one unit test for different controllers, the stub doesn't work in the second run.". There are several possible solutions, the main point is: you must make sure that the conditions for specific scenario/case are correctly prepared.
You can do:
create sandbox, to make sure no other stub service run between test cases.
start up fresh http (and or db) server before and shut down the server after the test run for each services, (for example: start the app and use real http client - as alternative to supertest)
run on debug mode to find out why the second stub not run or not get called or not work,
change implementation from stub to spy, you have already had a unit test, you just need to check whether the service get called or not, and then check the overall response.
Hope this helps.
I am writing React.js application talking to API server. I have read tons of articles on how to mock these calls and send some fake response from API. I can do testing using #testing-library/react, I can easily mock axios with axios-mock-adapter and test fetch requests using HTTP GET method. But I cannot find anywhere how to make sure that my app, when it sends some POST request, sends correct data to API, i.e. that my app sends json payload with e.g. "id" field, or "name" field set to "abc", or something like this.
I am new to React.js. Please advise how to make tests asserting what the app sends to API. Is it possible?
Let's say that I have a function named doSomething, like below, called with onClick of some button.
const doSomething = async (userId, something) => {
try {
await REST_API.post('doSomething', {
user_id: userId,
something: something
});
return true;
} catch (error) {
window.alert(error);
return false;
}
};
REST_API above is axios instance.
How can I ensure that the I (or some other developer) didn't make a typo and didn't put "userId" instead of "user_id" in the payload of the request?
If you have to be sure you call correctly the api, I'd use jest as follow:
jest.mock('axios', () => ({
post: jest.fn(),
}));
describe('test', () => {
it('doSomething', () => {
const userId = 123;
const something = 'abc';
doSomething(userId, something);
expect(axios.post).toBeCalledWith(
'doSomething', {
user_id: userId,
something,
},
);
});
});
or if you use instance, define it in another file (axios_instance.js) and using the follow test:
jest.mock('./axios_instance', () => ({
instance: {
post: jest.fn(),
},
}));
describe('test', () => {
it('doSomething', () => {
const userId = 123;
const something = 'abc';
doSomethingInstance(userId, something);
expect(instance.post).toBeCalledWith(
'doSomething', {
user_id: userId,
something,
},
);
});
});
For your need I would use Swagger and its tooling. You would kill three birds with one stone :
Have a proper API documentation : https://swagger.io/tools/swagger-ui/
Protect Backend : Ensure inputs/outputs are valid, and throw detailed exception if a client sends bad data : https://github.com/cdimascio/express-openapi-validator-example
Protect Frontend : Use client api generation to genrate js classes used by your clients .. That way they won't arbitrarily create objects manually and send them to server (crossing fingers) but use a dedicated API with setters : https://github.com/swagger-api/swagger-codegen
That way you have a rock solid Frontend + Backend + Documentation combo ..
i am using Jest to test my code.
What i want achieve is to test redirection from http to https. (if it exists if process.env.IS_PRODUCTION).
I don't know how to test it, how to mockup this and so on...
I've tried standard get reqest but don't know how to mockup environment varible or test it in different way
it('should redirect from http to https, (done) => {
request(server)
.get('/')
.expect(301)
.end((err, res) => {
if (err) return done(err);
expect(res.text).toBe('...')
return done();
});
}, 5000);
I expect to be able to test this redirection :)
You could use the node-mocks-http libary which allows you to simulate a request and response object.
Example:
const request = httpMocks.createRequest({
method: 'POST',
url: '/',
});
const response = httpMocks.createResponse();
middlewareThatHandlesRedirect(request, response);
I never worked with jest but I believe that you can check the response.location parameter once the middleware has been called
Preface: I'm not familiar with jest or express or node. But I have found it to be much easier to test explicit configuration (instantiating objects with explicit values) vs implicit configuration (environmental variables and implementation switches on them):
I'm not sure what request or server are but explicit approach might look like:
it('should redirect from http to https, (done) => {
const server = new Server({
redirect_http_to_https: true,
});
request(server)
.get('/')
.expect(301)
.end((err, res) => {
if (err) return done(err);
expect(res.text).toBe('...')
return done();
});
}, 5000);
This allows the test to explicitly configure server to the state it needs instead of mucking with the environment.
This approach also helps to keep process configuration at the top level of your application:
const server = new Server({
redirect_http_to_https: process.env.IS_PRODUCTION,
});
I'm building an electron app and need to call APIs where the API provider has not enabled CORS. The typically proposed solution is to use a reverse proxy which is trivial to do when running locally by using node and cors-anywhere like this:
let port = (process.argv.length > 2) ? parseInt (process.argv[2]) : 8080;
require ('cors-anywhere').createServer ().listen (port, 'localhost');
The app can then be configured to proxy all requests through the reverse proxy on localhost:8080.
So, my questions are:
Is it possible to use node and cors-anywhere in an electron app to create a reverse proxy? I don't want to force the app to make calls to a remote server.
Is there a better or standard way of doing this in an Electron app? I'm assuming I'm not the first to run into CORS issues. :)
Just overide header before send request using webRequest.onBeforeSendHeaders
const filter = {
urls: ['*://*.google.com/*']
};
const session = electron.remote.session
session.defaultSession.webRequest.onBeforeSendHeaders(filter, (details, callback) => {
details.requestHeaders['Origin'] = null;
details.headers['Origin'] = null;
callback({ requestHeaders: details.requestHeaders })
});
put these codes in renderer process
In my application, it wasn't sufficient to remove the Origin header (by setting it to null) in the request. The server I was passing the request to always provided the Access-Control-Allow-Origin header in the response, regardless of it the Origin header is present in the request. So the embedded instance of Chrome did not like that the ACAO header did not match its understanding of the origin.
Instead, I had to change the Origin header on the request and then restore it on the Access-Control-Allow-Origin header on the response.
app.on('ready', () => {
// Modify the origin for all requests to the following urls.
const filter = {
urls: ['http://example.com/*']
};
session.defaultSession.webRequest.onBeforeSendHeaders(
filter,
(details, callback) => {
console.log(details);
details.requestHeaders['Origin'] = 'http://example.com';
callback({ requestHeaders: details.requestHeaders });
}
);
session.defaultSession.webRequest.onHeadersReceived(
filter,
(details, callback) => {
console.log(details);
details.responseHeaders['Access-Control-Allow-Origin'] = [
'capacitor-electron://-'
];
callback({ responseHeaders: details.responseHeaders });
}
);
myCapacitorApp.init();
});
Try this if you are running web apps in localhost
const filter = {
urls: ['http://example.com/*'] // Remote API URS for which you are getting CORS error
}
browserWindow.webContents.session.webRequest.onBeforeSendHeaders(
filter,
(details, callback) => {
details.requestHeaders.Origin = `http://example.com/*`
callback({ requestHeaders: details.requestHeaders })
}
)
browserWindow.webContents.session.webRequest.onHeadersReceived(
filter,
(details, callback) => {
details.responseHeaders['access-control-allow-origin'] = [
'capacitor-electron://-',
'http://localhost:3000' // URL your local electron app hosted
]
callback({ responseHeaders: details.responseHeaders })
}
)
Just had this issue today API calls with axios inside a React app bundled in Electron is returning 400
From what I can see Electron calls act as normal calls to the API urls meaning they are not affected by CORS.
Now when you wrap your calls with a CORS proxy and make a regular call to the proxy, it should error with a 400 error because it's not a CORS call.
This thread explains why cors-anywhere responds like that => https://github.com/Rob--W/cors-anywhere/issues/39
I actually removed my CORS proxies from the app before the Electron build. I still need the CORS proxy for development since I'm testing in the browser.
Hope this helps.
You can have the main process, the NodeJS server running Electron, send the request. This avoids CORS because this is a server-to-server request. You can send an event from the frontend (the render process) to the main process using IPC. In the main process you can listen to this event, send the HTTP request, and return a promise to the frontend.
In main.js (the script where the Electron window is created):
import { app, protocol, BrowserWindow, ipcMain } from ‘electron’
import axios from 'axios'
ipcMain.handle('auth', async (event, ...args) => {
console.log('main: auth', event, args) const result = await axios.post(
'https://api.com/auth',
{
username: args[0].username,
password: args[0].password,
auth_type: args[1],
},
) console.log('main: auth result', result)
console.log('main: auth result.data', result.data) return result.data
})
In your frontend JS:
import { ipcRenderer } from 'electron'
sendAuthRequestUsingIpc() {
return ipcRenderer.invoke('auth',
{
username: AuthService.username,
password: AuthService.password,
},
'password',
).then((data) => {
AuthService.AUTH_TOKEN = data['access_token']
return true
}).catch((resp) => console.warn(resp))
}
I wrote an article that goes into more depth here.
While I have struggled a while with the existing answers I will provide here the solution that finally worked for me, assuming that you are on the main process.
Here are the steps involved:
You need to have access to the session object which can be obtained by one of two ways:
A) via the global session.defaultSession which is available after the app is ready.
const { session } = require('electron');
const curSession = session.defaultSession;
B) The other method is via the session on the BrowserWindow, this assumes that the windnows is already created.
win = new BrowserWindow({});
const curSession = win.webContents.session;
Once you have the session object you set the response header to the site you are sending the request from.
For example, let's say your electron BrowserWindow is loaded from http://localhost:3000 and you are making a request to example.com, here would be some sample code:
const { app, BrowserWindow, session } = require('electron');
app.whenReady().then(_ => {
// If using method B for the session you should first construct the BrowserWindow
const filter = { urls: ['*://*.example.com/*'] };
session.defaultSession.webRequest.onHeadersReceived(filter, (details, callback) => {
details.responseHeaders['Access-Control-Allow-Origin'] = [ 'http://localhost:3000' ];
callback({ responseHeaders: details.responseHeaders });
}
// Construct the BrowserWindow if haven't done so yet...
});
Have you tried using fetch()
Check how to use fetch to make a no-cors request here
https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en