I have the following testcase:
it('User can logout', async () => {
await helper.navClick('.header-user-action__logout');
const url = page.url();
console.log(url)
await expect(url).toContain('auth');
});
helper.navClick is just a small wrapper:
async function navClick(selector, options) {
return await Promise.all([page.waitForNavigation(), expect(page).toClick(selector, options)]);
}
Most of the time, it succeeds without any problem, but sometimes it'll be marked as failed:
✕ User can logout (569 ms)
● Login › User can logout
console.log
https://auth.example.com/auth/realms/example/protocol/openid-connect/auth?response_type=code&client_id=example-app&redirect_uri=https%3A%2F%2Fexample.com%2Fsso%2Flogin&state=807469fd-3ee5-4d93-8354-ca47a63e69a6&login=true&scope=openid
How can this happen? The url contains "auth" multiple times, and I don't see anything else that could cause the test to fail.
I found the issue by setting up a custom environment:
const PuppeteerEnvironment = require("jest-environment-puppeteer");
const util = require('util');
class DebugEnv extends PuppeteerEnvironment {
async handleTestEvent(event, state) {
const ignoredEvents = ['setup', 'add_hook', 'start_describe_definition', 'add_test', 'finish_describe_definition', 'run_start',
'run_describe_start', 'test_start', 'hook_start', 'hook_success', 'test_fn_start', 'test_fn_success', 'test_done',
'run_describe_finish', 'run_finish', 'teardown'];
if (!ignoredEvents.includes(event.name)) {
console.log(new Date().toString() + " Unhandled event(" + event.name + "): " + util.inspect(event));
}
}
}
module.exports = DebugEnv;
In my package.json, I set the testEnvironment to this DebugEnv:
"jest": {
"preset": "jest-puppeteer",
"testEnvironment": "./debugenv.js",
By doing this, I found an error which had nothing to with the test itself (network related if I recall correctly).
Related
We want to fail the build if more console errors are introduced. For example, let's say console.error was called 30 times in the whole test suite. If another error is introduced this will increase to 31, which we don't want. Is there a way to prevent this?
For one test suite it is possible with:
const spy = jest.spyOn(console, "error");
let count = 0;
afterEach(() => {
count += spy.mock.calls.length;
});
afterAll(() => {
if (count > 2) {
throw Error(`oops error count: ${count}`);
}
});
but it would be nice to have this globally defined.
We solved this in a slightly different way:
// src/utils/testUtils
let consoleErrorSpy;
export const spyOnConsoleError = () => {
consoleErrorSpy = jest.spyOn(console, "error");
};
/**
* We are using this to prevent the console errors from increasing.
* These are our preferences in order of priority:
* 1. Don't call this method
* 2. Call this method at the end of a specific test (eg. for an error that can't be solved)
* 3. Call this method in `afterEach` (eg. for an async error that can't be solved)
*/
export const catchConsoleErrors = ({ silenced = [] } = {}) => {
const alwaysSilencedErrors = [
'<bug from a 3rd party library>'
];
const forbiddenCalls = [];
const silencedCalls = [];
for (const call of consoleErrorSpy.mock.calls) {
if (
new RegExp([...alwaysSilencedErrors, ...silenced].join("|")).test(call)
) {
silencedCalls.push(call);
} else {
forbiddenCalls.push(call);
}
}
for (const silencedCall of silencedCalls) {
// eslint-disable-next-line no-console
console.log("SILENCED\n---\n" + silencedCall.join(",") + "\n---");
}
expect(forbiddenCalls).toHaveLength(0);
// We clear the mock here so nothing happens if the method is called again for the same test,
// which is the case when this method is called in a specific test (file)
// as it is also called in `afterEach` in setUpTests.js
consoleErrorSpy.mockClear();
};
// some test file
afterEach(() => {
catchConsoleErrors({
silenced: [
"Warning: Can't perform a React state update on an unmounted component.*"
]
});
});
// src/setupTests.js
spyOnConsoleError();
afterEach(() => {
catchConsoleErrors();
});
With top-level await accepted into ES2022, I wonder if it is save to assume that await import("./path/to/module") has no timeout at all.
Here is what I’d like to do:
// src/commands/do-a.mjs
console.log("Doing a...");
await doSomethingThatTakesHours();
console.log("Done.");
// src/commands/do-b.mjs
console.log("Doing b...");
await doSomethingElseThatTakesDays();
console.log("Done.");
// src/commands/do-everything.mjs
await import("./do-a");
await import("./do-b");
And here is what I expect to see when running node src/commands/do-everything.mjs:
Doing a...
Done.
Doing b...
Done.
I could not find any mentions of top-level await timeout, but I wonder if what I’m trying to do is a misuse of the feature. In theory Node.js (or Deno) might throw an exception after reaching some predefined time cap (say, 30 seconds).
Here is how I’ve been approaching the same task before TLA:
// src/commands/do-a.cjs
import { autoStartCommandIfNeeded } from "#kachkaev/commands";
const doA = async () => {
console.log("Doing a...");
await doSomethingThatTakesHours();
console.log("Done.");
}
export default doA;
autoStartCommandIfNeeded(doA, __filename);
// src/commands/do-b.cjs
import { autoStartCommandIfNeeded } from "#kachkaev/commands";
const doB = async () => {
console.log("Doing b...");
await doSomethingThatTakesDays();
console.log("Done.");
}
export default doB;
autoStartCommandIfNeeded(doB, __filename);
// src/commands/do-everything.cjs
import { autoStartCommandIfNeeded } from "#kachkaev/commands";
import doA from "./do-a";
import doB from "./do-b";
const doEverything = () => {
await doA();
await doB();
}
export default doEverything;
autoStartCommandIfNeeded(doEverything, __filename);
autoStartCommandIfNeeded() executes the function if __filename matches require.main?.filename.
Answer: No, there is not a top-level timeout on an await.
This feature is actually being used in Deno for a webserver for example:
import { serve } from "https://deno.land/std#0.103.0/http/server.ts";
const server = serve({ port: 8080 });
console.log(`HTTP webserver running. Access it at: http://localhost:8080/`);
console.log("A");
for await (const request of server) {
let bodyContent = "Your user-agent is:\n\n";
bodyContent += request.headers.get("user-agent") || "Unknown";
request.respond({ status: 200, body: bodyContent });
}
console.log("B");
In this example, "A" gets printed in the console and "B" isn't until the webserver is shut down (which doesn't automatically happen).
As far as I know, there is no timeout by default in async-await. There is the await-timeout package, for example, that is adding a timeout behavior. Example:
import Timeout from 'await-timeout';
const timer = new Timeout();
try {
await Promise.race([
fetch('https://example.com'),
timer.set(1000, 'Timeout!')
]);
} finally {
timer.clear();
}
Taken from the docs: https://www.npmjs.com/package/await-timeout
As you can see, a Timeout is instantiated and its set method defines the timeout and the timeout message.
I'm trying to run next build when using getStaticProps and getStaticPaths method in one of my routes, but it fails every time. Firstly, it just couldn't connect to my API (which is obvious, they're created using Next.js' API routes which are not available when not running a Next.js app). I thought that maybe running a development server in the background would help. It did, but generated another problems, like these:
Error: Cannot find module for page: /reader/[id]
Error: Cannot find module for page: /
> Build error occurred
Error: Export encountered errors on following paths:
/
/reader/1
Dunno why. Here's the code of /reader/[id]:
const Reader = ({ reader }) => {
const router = useRouter();
return (
<Layout>
<pre>{JSON.stringify(reader, null, 2)}</pre>
</Layout>
);
};
export async function getStaticPaths() {
const response = await fetch("http://localhost:3000/api/readers");
const result: IReader[] = await response.json();
const paths = result.map((result) => ({
params: { id: result.id.toString() },
}));
return {
paths,
fallback: false,
};
}
export async function getStaticProps({ params }) {
const res = await fetch("http://localhost:3000/api/readers/" + params.id);
const result = await res.json();
return { props: { reader: result } };
}
export default Reader;
Nothing special. Code I literally rewritten from the docs and adapted for my site.
And here's the /api/readers/[id] handler.
export default async function handler(
req: NextApiRequest,
res: NextApiResponse
) {
const knex = getKnex();
const { id } = req.query;
switch (req.method) {
case "GET":
try {
const reader = await knex
.select("*")
.from("readers")
.where("id", id)
.first();
res.status(200).json(reader);
} catch {
res.status(500).end();
}
break;
}
}
Nothing special either. So why is it crashing every time I try to build my app? Thanks for any help in advance.
You should not fetch an internal API route from getStaticProps — instead, you can write the fetch code present in API route directly in getStaticProps.
https://nextjs.org/docs/basic-features/data-fetching#write-server-side-code-directly
i am trying to test hapijs with server.inject
/// <reference path="../../typings/index.d.ts" />
import * as chai from "chai";
let assert = chai.assert;
import server from "../../src/server";
import UserController from '../../src/controllers/userController';
import UserRepository from '../../src/libs/repository/mongo/userRepository';
import {IUser, IUserActivation, IUserCreate} from "../../src/libs/repository/interfaces";
describe("routes/user", function() {
const userController = new UserController(server, new UserRepository());
// ========================== [ ACTIVATE ] ==========================
it.only("/activate: should activate a user", function(done) {
let user: IUserActivation = {
'_id': '1234566737465',
'token': '123234523542345'
};
let url = '/api/users/' + user._id + '/' + user.token;
const request = {
method: 'PUT',
url: url,
payload: user
};
server.inject(request).then((response) => {
let res = JSON.parse(response.payload);
//assert.strictEqual(res.success, true, '/users/{id}/{token}')
chai.expect(res.success).to.deep.equal(false);
chai.expect(res.success).to.deep.equal(true);
done();
}).catch((error) => {
console.log(error.message);
});
});
});
The response.success attribute is true. So normally the test should fail because of chai.expect(res.success).to.deep.equal(false);.
But the test fails with the message: Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.
When removing the catch clause it also fails with the timeout error.
If I add done() to the end of the catch-clause the test is passing. That is wrong behavior, because the test should fail.
What can i do to get the expected behavior? thanks in advance.
The problem would be that server.inject returns a promise. As long as your using a recent version of Mocha, it can handle that but you don't need to worry about calling done() and rather return the server.inject.
describe("routes/user", function() {
const userController = new UserController(server, new UserRepository());
// ========================== [ ACTIVATE ] ==========================
it.only("/activate: should activate a user", function() { //No done needed
let user: IUserActivation = {
'_id': '1234566737465',
'token': '123234523542345'
};
let url = '/api/users/' + user._id + '/' + user.token;
const request = {
method: 'PUT',
url: url,
payload: user
};
//Return the promise
return server.inject(request).then((response) => {
let res = JSON.parse(response.payload);
//assert.strictEqual(res.success, true, '/users/{id}/{token}')
chai.expect(res.success).to.deep.equal(false);
chai.expect(res.success).to.deep.equal(true);
}); //No catch needed.
});
});
I'm trying to run a series of tests dynamically. I have the following setup but it doesn't seem to run and I'm not getting any errors:
import Mocha from 'mocha';
const Test = Mocha.Test;
const Suite = Mocha.Suite;
const mocha = new Mocha();
for (let s in tests) {
let suite = Suite.create(mocha.suite, s);
tests[s].forEach((test) => {
console.log('add test', test.name)
suite.addTest(new Test(test.name), () => {
expect(1+1).to.equal(2);
});
});
}
mocha.run();
The tests I'm running look like this:
{ todo:
[ { name: 'POST /todos',
should: 'create a new todo',
method: 'POST',
endpoint: '/todos',
body: [Object] } ] }
(though at this point my test is just trying to check a basic expect)
Based on the console.logs the iteration seems fine and it appears to be adding the tests, so I'm confident in the flow of operations, I just can't get any execution or errors.
You have to pass the test function to the Test constructor, not to suite.addTest. So change your code to add your tests like this:
suite.addTest(new Test(test.name, () => {
expect(1+1).to.equal(2);
}));
Here is the entire code I'm running, adapted from your question:
import Mocha from 'mocha';
import { expect } from 'chai';
const Test = Mocha.Test;
const Suite = Mocha.Suite;
const mocha = new Mocha();
var tests = { todo:
[ { name: 'POST /todos',
should: 'create a new todo',
method: 'POST',
endpoint: '/todos',
body: [Object] } ] };
for (let s in tests) {
let suite = Suite.create(mocha.suite, s);
tests[s].forEach((test) => {
console.log('add test', test.name);
suite.addTest(new Test(test.name, () => {
expect(1+1).to.equal(2);
}));
});
}
mocha.run();
When I run the above with node_modules/.bin/babel-node test.es6, I get the output:
todo
✓ POST /todos
1 passing (5ms)
It's critical to test your test system and make sure it deals with passing and failing tests and thrown exceptions.
Since folks are counting on a build process to warn them about errors, you must also set the exit code to a non-zero if anything failed.
Below is a test script (which you must invoke with node test.js rather than mocha test.js) which exercises all paths through your test suite:
const Mocha = require('mocha')
const expect = require('chai').expect
var testRunner = new Mocha()
var testSuite = Mocha.Suite.create(testRunner.suite, 'Dynamic tests')
var tests = [ // Define some tasks to add to test suite.
{ name: 'POST /todos', f: () => true }, // Pass a test.
{ name: 'GET /nonos', f: () => false }, // Fail a test.
{ name: 'HEAD /hahas', f: () => { throw Error(0) } } // Throw an error.
]
tests.forEach(
test =>
// Create a test which value errors and caught exceptions.
testSuite.addTest(new Mocha.Test(test.name, function () {
expect(test.f()).to.be.true
}))
)
var suiteRun = testRunner.run() // Run the tests
process.on('exit', (code) => { // and set exit code.
process.exit(suiteRun.stats.failures > 0) // Non-zero exit indicates errors.
}) // Falling off end waits for Mocha events to finish.
Given that this is prominent in web searches for asynchronous mocha tests, I'll provide a couple more useful templates for folks to copy.
Embedded execution: The first directly adds tests which invoke an asynchronous faux-network call and check the result in a .then:
const Mocha = require('mocha')
const expect = require('chai').expect
var testRunner = new Mocha()
var testSuite = Mocha.Suite.create(testRunner.suite, 'Network tests')
var tests = [ // Define some long async tasks.
{ name: 'POST /todos', pass: true, wait: 3500, exception: null },
{ name: 'GET /nonos', pass: false, wait: 2500, exception: null },
{ name: 'HEAD /hahas', pass: true, wait: 1500, exception: 'no route to host' }
]
tests.forEach(
test =>
// Create a test which value errors and caught exceptions.
testSuite.addTest(new Mocha.Test(test.name, function () {
this.timeout(test.wait + 100) // so we can set waits above 2000ms
return asynchStuff(test).then(asyncResult => {
expect(asyncResult.pass).to.be.true
}) // No .catch() needed because Mocha.Test() handles them.
}))
)
var suiteRun = testRunner.run() // Run the tests
process.on('exit', (code) => { // and set exit code.
process.exit(suiteRun.stats.failures > 0) // Non-zero exit indicates errors.
}) // Falling off end waits for Mocha events to finish.
function asynchStuff (test) {
return new Promise(function(resolve, reject) {
setTimeout(() => {
// console.log(test.name + ' on ' + test.endpoint + ': ' + test.wait + 'ms')
if (test.exception)
reject(Error(test.exception))
resolve({name: test.name, pass: test.pass}) // only need name and pass
}, test.wait)
})
}
This code handles passing and failing data, reports exceptions, and exits with a non-zero status if there were errors. The output reports all expected problems and additionally whines about the test taking a like time (3.5s):
Network tests
✓ POST /todos (3504ms)
1) GET /nonos
2) HEAD /hahas
1 passing (8s)
2 failing
1) Network tests GET /nonos:
AssertionError: expected false to be true
+ expected - actual
-false
+true
2) Network tests HEAD /hahas:
Error: no route to host
Delayed execution: This approach invokes all of the slow tasks before populating and starting the the mocha test suite:
const Mocha = require('mocha')
const expect = require('chai').expect
var testRunner = new Mocha()
var testSuite = Mocha.Suite.create(testRunner.suite, 'Network tests')
var tests = [ // Define some long async tasks.
{ name: 'POST /todos', pass: true, wait: 3500, exception: null },
{ name: 'GET /nonos', pass: false, wait: 2500, exception: null },
{ name: 'HEAD /hahas', pass: true, wait: 1500, exception: 'no route to host' }
]
Promise.all(tests.map( // Wait for all async operations to finish.
test => asynchStuff(test)
.catch(e => { // Resolve caught errors so Promise.all() finishes.
return {name: test.name, caughtError: e}
})
)).then(testList => // When all are done,
testList.map( // for each result,
asyncResult => // test value errors and exceptions.
testSuite.addTest(new Mocha.Test(asyncResult.name, function () {
if (asyncResult.caughtError) { // Check test object for caught errors
throw asyncResult.caughtError
}
expect(asyncResult.pass).to.be.true
}))
)
).then(x => { // When all tests are created,
var suiteRun = testRunner.run() // run the tests
process.on('exit', (code) => { // and set exit code.
process.exit(suiteRun.stats.failures > 0) // Non-zero exit indicates errors.
})
})
function asynchStuff (test) {
return new Promise(function(resolve, reject) {
setTimeout(() => {
// console.log(test.name + ' on ' + test.endpoint + ': ' + test.wait + 'ms')
if (test.exception)
reject(Error(test.exception))
resolve({name: test.name, pass: test.pass}) // only need name and pass
}, test.wait)
})
}
The output is the same except that mocha doesn't whine about the slow test and instead believes the tests tool less than 10ms. The Promise.all waits for all the promises to resolve or reject then creates the tests to validate the results or report exceptions. This is a few lines longer than Embedded execution because it must:
Resolve exceptions so Promise.all() resolves.
Execute the tests in a final Promise.all().then()
Comments describing how folks pick which style to use could guide others. Share your wisdom!