I am using Mocha with chai to perform unit testing. But I can't comprehend the error messages displayed when a test fails.
For instance, I have a simple api, that only accepts alpha characters for certain inputs. If the user attempts to submit something like "3rror", the api will return a status of 403, or some other error code.
With Mocha I can assert something like : response.should.have.status(403); to check the server is catching and serving invalid requests appropriately.
However; with Mocha, I am completely lost when trying to reason out why or what caused an error to occur. Did I write a bad test, did my sanitization/validation middleware fail, am I even connected to my server, or am I failing to handle invalid requests and/or errors appropriately?
Below is an example of an error message Mocha provides for the mentioned case.
Uncaught TypeError: Cannot read properties of undefined (reading 'should')
at C:\...\test.js:53:43
at Test.Request.callback (node_modules\chai-http\node_modules\superagent\lib\node\index.js:716:12)
at IncomingMessage.<anonymous> (node_modules\chai-http\node_modules\superagent\lib\node\index.js:916:18)
at IncomingMessage.emit (node:events:539:35)
at endReadableNT (node:internal/streams/readable:1345:12)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
I understand it gave the wrong status code, but these error messages don't really help me understand what went wrong. Did I just goof an write a bad test, or did my app fail? So I am here to ask for help.
How can I better understand these errors reported when a test fails using Mocha?
Related
thank you for looking into this!
We are running a quite comprehensive testsuite (some hunderds of test) with the goal to make sure that our tracking implemantation works as expected. We are executing this tests via CI 4x a day. Since a few weeks we have random test aborts, which are unfortunately extremely hard to track and reproduce.
What is the Current behavior?
Errors: Unhandled promise rejection:
Error [ERR_HTTP2_INVALID_SESSION]: The session has been destroyed
at new NodeError (node:internal/errors:371:5)
at ClientHttp2Session.request (node:internal/http2/core:1702:13)
at DestinationRequest._sendRealThroughHttp2 (/home/ec2-user/actions-runner/_work/ds_cerberus/ds_cerberus/node_modules/testcafe-hammerhead/lib/request-pipeline/destination-request/index.js:51:32)
at DestinationRequest._send (/home/ec2-user/actions-runner/_work/ds_cerberus/ds_cerberus/node_modules/testcafe-hammerhead/lib/request-pipeline/destination-request/index.js:110:18)
at runMicrotasks (:null:null)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
For us it looks like a racing condition inside the hammerhead-lib which is used as a proxy for testcafe. But we have no idea how to fix this - or least make sure that not the whole suite of tests is aborted by it.
This is the stacktrace if the tests are aborted. Unfortunately this means that the execution of all tests is aborted and does not only affect a single test, which renders the whole suite for us pretty useless...
Steps to Reproduce
There seems to be more aborts if the tests are executed in the suite and not solely - but even there it is quite hard to identify a pattern.
TestCafe version
"testcafe": "^1.17.1",
Node.js version
node-version: '16.x'
Command-line arguments
testcafe --config-file .testcaferc-dev.json tests
The issue may be related to HTTP/2 requests. So, you can disable it using the following option: disableHttp2. Check if the issue is reproduced after that.
You can also try to increase timeouts, e.g. ajaxRequestTimeout and testExecutionTimeout.
If this does not help, please create a simple project where the issue is reproducible and share it here. We will research it on our side.
I am using webdriverIO v7 and cucumber to test my application.
I have feature file with 10 scenarios.
What happens is that when I run the test then first 4 scenarios are executed seamlessly and on the fifth scenario all of sudden I get the error:
unknown error: java.net.ConnectException: Connection refused: connect
at Object.getErrorFromResponseBody (C:\my-project\node_modules\webdriver\build\utils.js:189:12)
at WebDriverRequest._request (C:\my-project\node_modules\webdriver\build\request.js:168:31)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at Browser.runCommandWithHooks (C:\my-project\node_modules\#wdio\sync\build\wrapCommand.js:105:25)
at Browser.runCommandWithHooks (C:\my-project\node_modules\#wdio\sync\build\wrapCommand.js:100:24)
at Browser.url (C:\my-project\node_modules\#wdio\sync\build\wrapCommand.js:67:44)
at MyPage.openImportPage (C:\my-project\src\pages\/myPage.js:32:17)
at forEach (C:\my-project\src\helpers\/helpers.js:60:21)
at Array.forEach (<anonymous>)
at Helpers.deleteWishLists (C:\my-project\src\helpers\/helpers.js:55:51)
at World.<anonymous> (C:\my-project\src\step_definitions\/config_steps.js:28:13)
at World.executeSync (C:\my-project\node_modules\#wdio\sync\build\index.js:38:22)
at World.executeSync (C:\my-project\node_modules\#wdio\sync\build\index.js:52:38)
at C:\my-project\node_modules\#wdio\sync\build\index.js:69:68
The first step of the fifth scenario is also executed in previous scenarios which succeeded normally.
It doesn't behave consistently - for example, when running for the second time in non headless mode all scenarios passed (all of a sudden).
Running in headless mode, sometimes all scenarios fail with that exception, sometimes only some fail - no rule to notice there.
It is very confusing. I assume it has nothing to do with my tests since sometimes they are all passing, but has to do with my setup or internet connection or webdriverIO framework and its standalone mode ...
Does anybody have clue why is this happening. Who is the trouble maker here?
I don't even know in which direction should I look to in order to investigate this.
Please help.
Thanks!
At the end the issue was with my internet connection.
Guys from wdio made small patch for it:
https://github.com/webdriverio/webdriverio/issues/6728
My node js application ( a discord bot ) keeps crashing with the Error: aborted message and code ECONNRESET. I have some some digging and it seems that the issue occurs when the other end of a TCP connection hangs up abruptly.
The error message I always get:
Error: aborted
at connResetException (node:internal/errors:631:14)
at TLSSocket.socketCloseListener (node:_http_client:438:27)
at TLSSocket.emit (node:events:388:22)
at node:net:666:12
at TCP.done (node:_tls_wrap:573:7) {
code: 'ECONNRESET'
}
As you can see the error message is not very useful and doesn't provide any informatino as to where the error happened. I am getting the error through the node process.on('uncaughtException', err => {}) exception handler.
I am using discord.js ^12.5.1 node 15.4.0 and axios ^0.21.1 although the error seems to occur randomly and looking through the logs there is never a specific function call that triggers it and sometimes it happens whilst no functions have even been called.
The error happens sporadically as well. Sometimes it happens once a day and other times it will happen 5 times in an hour.
I should also add I am using the Heroku free tier for hosting,
If anyone could shed some light that would be very useful.
I have a node webapp that makes various API calls to Stripe using the stripe npm package. Sometimes I get errors like the one below. Notice that the stacktrace is truncated so that I cannot see which stripe API call causes the error and I also cannot see where in my app this API call is made.
Is there anything I can do to get better error stacktraces?
Error: Missing required param: customer.
at Function.generate (/home/molsson/dv/foobar/node_modules/stripe/lib/Error.js:39:16)
at IncomingMessage.<anonymous> (/home/molsson/dv/foobar/node_modules/stripe/lib/StripeResource.js:175:33)
at Object.onceWrapper (events.js:299:28)
at IncomingMessage.emit (events.js:215:7)
at IncomingMessage.EventEmitter.emit (domain.js:476:20)
at endReadableNT (_stream_readable.js:1183:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Note: the error itself is just an example. I have already fixed it. I just want to get better stacktraces or a better method of debugging these types of errors quickly.
I'm pretty sure my node version has async stacks by default:
$ node --version
v12.12.0
$ node -p process.versions.v8
7.7.299.13-node.12
I tried running with NODE_OPTIONS='--trace-warnings --stack-trace-limit=9999' but it didn't help.
Does it exists some kind of "async stacktraces across event emitters" debugging thing?
I found a good answer to this question myself. The stripe library fires and event before making a new API request, so you can print a stacktrace from there:
stripe.on('request', request => {
const currentStack = (new Error()).stack.replace(/^Error/, '')
console.log(`Making Stripe HTTP request to ${request.path}, callsite: ${currentStack}`)
})
I added a STRIPE_API_TRACING option to my app that I can turn on if I experience errors without stacks. With the tracing on I can just scroll a bit up in the log and see what API calls was dispatched just before the error happened.
I used swagger (swagger.io) to built my app's API and everything works fine in production environment. However, when I ran some mocha tests on these APIs, I keep getting this error regarding status code 429 Too Many Requests:
Unhandled rejection Error: Too Many Requests
at Request.callback (..../node_modules/superagent/lib/node/index.js:698:17)
at IncomingMessage.<anonymous> (..../node_modules/superagent/lib/node/index.js:922:12)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:926:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickDomainCallback (internal/process/next_tick.js:122:9)
Usually this error happens after I ran the mocha test twice in a row (ie start throwing this error from the third time onwards). I suspected I was overloading my localhost server, but the error persisted even after I closed and reopened the server.
Would be super grateful if someone could point me towards the right direction to solve this problem.