When launched through the intern-runner command, my tests are still hanging--intern-runner never exits to give me a report and I can tell that the proxy server is still running on port 9000. The browser I specified through my config just remains open (and no, I did not set leaveRemoteOpen to true). I added some debug to lib/reporters/webdriver.js, because I saw that's what logged the "Tests complete" message. I could see that the topic.publish('/client/end') code was invoked, but nothing ever responded to this event. Doesn't lib/ClientSuite subscribe to this topic? From that module:
topic.subscribe('/client/end', function (sessionId) {
console.log("subscribed to '/client/end' for session", sessionId);
if (sessionId === remote.session.sessionId) {
clearHandles();
// get about:blank to always collect code coverage data from the page in case it is
// navigated away later by some other process; this happens during self-testing when
// the new Leadfoot library takes over
remote.setHeartbeatInterval(0).get('about:blank').then(lang.hitch(dfd, 'resolve'));
}
})
But nothing ever happens, and I don't see my console.log() output. Sorry if I am bringing up things that are red herrings, but I just wanted to do some initial investigation first.
All I want is for my test to end and my JUnit and LCOV reports generated! :( What could be going wrong?
And note: no error messages are logged to the command terminal from which I invoked intern-runner config=unittest/myInternConfig. No errors (obvious ones at least) appear in terminal where Selenium server is running.
Update 03/15/15: I added this info in my last comment, but maybe comments get lost in the shuffle on Stackoverflow. In our legacy DOH tests, we used Sinon to fake a server so as to not make real I/O requests to the backend server in unittests. I didn't see a problem with keeping this in the Intern tests, but apparently, there is. When I disabled the test modules that just do
var server = sinon.fakeServer.create();
(well, that, in addition to calling server.respondWith() and server.respond())
intern-runner completed, I got my reports, and etc. Then I searched for "intern with sinon" and stumbled upon https://github.com/theintern/intern/issues/47, where jason0x43 linked to his Sinon-with-Intern code at https://github.com/theintern/intern/blob/sinon/sinon.js. So, I found that very helpful--it seems that in my situation, Sinon's FakeXMLHttpRequest was ALSO faking requests to Intern's proxy server, and that was what was hanging the process.
So, after pretty much using jason0x43's sinon.js code to filter out the "real request," I re-enabled the problematic test modules, re-ran, and everything worked beautifully.
Again, no errors or any sort of warnings reported in terminal or browser console--it would be great if there could be some sort of head's up about this pitfall. Even if just in a Readme file.
(I also edited my original post to add this info.) In our legacy DOH tests, we used Sinon to fake a server so as to not make real I/O requests to the backend server in unittests. I didn't see a problem with keeping this in the Intern tests, but apparently, there is. When I disabled the test modules that just do
var server = sinon.fakeServer.create();
(well, that, in addition to calling server.respondWith() and server.respond())
intern-runner completed, I got my reports, and etc. Then I searched for "intern with sinon" and stumbled upon https://github.com/theintern/intern/issues/47, where jason0x43 linked to his Sinon-with-Intern code at https://github.com/theintern/intern/blob/sinon/sinon.js. So, I found that very helpful--it seems that in my situation, Sinon's FakeXMLHttpRequest was ALSO faking requests to Intern's proxy server, and that was what was hanging the process.
So, after pretty much using jason0x43's sinon.js code to filter out the "real request," I re-enabled the problematic test modules, re-ran, and everything worked beautifully.
Again, no errors or any sort of warnings reported in terminal or browser console--it would be great if there could be some sort of head's up about this pitfall. Even if just in a Readme file.
Related
NOTE: This is mainly a question about the pg or Node-PostgreSQL module. It has details from Gatsby and Postgraphile, but I don't need expertise in all three, just pg.
I have a database that works great with a PostGraphile-using Express server. I can also acces it via node at the command line ...
const { Pool } = require("pg");
const pool = new Pool({ connectionString: myDbUrl });
pool.connect().then(() => console.log('connected'));
// logs 'connected' immediately
The exact same database also previously worked great with Gatsby/PostGraphile via the gatsby-source-pg plug-in ... but recently I changed dev machines, and when I try to build or run a dev server, Gatsby hangs on the "source and transform nodes" step. When I debug it, it's hanging on a call to pool.connect().
So I literally have two codebases both using PostGraphile, both with the same config, and one works and the other doesn't. Even stranger, if I edit the source code of the Gatsby plug-in in node_modules, to make it use the exact same code (which I can run at the command line successfully) ... it still hangs.
The only thing I can think of is that some other Gatsby plug-in is using up all the connections and not releasing them, but as far as I can tell (eg. by grep-ing through node_modules) no other plug-in even uses pg.
So really I have two questions:
A) Can anyone help me understand why connect would hang? Bonus points if you can help me understand why it would do so with a known-good config and only inside Gatsby (after some environmental factor changed)?
B) Can anyone help me fix it? If it might be some sort of "previous code forgot to release connections" issue, is there any way I can test for that? If I could just log new Pool().areYouBroken() somehow that would be amazingly useful.
Try:
npm install pg#latest
This is what got my pool/connection to start working as expected.
Annoying answer: because of a bug (thank you #charmander). For further details see: https://github.com/brianc/node-postgres/issues/2300
P.S. I never did find any sort of new Pool().areYouBroken() function.
I am running my integration test cases in separate files for each API.
Before it begins I start the server along with all services, like databases. When it ends, I close all connections. I use Before and After hooks for that purpose. It is important to know that my application depends on an enterprise framework where most "core work" is written and I install it as a dependency of my application.
I run the tests with Mocha.
When the first file runs, I see no problems. When the second file runs I get a lot of errors related to database connections. I tried to fix it in many different ways, most of them failed because of the limitations the Framework imposed me.
Debugging I found out that Mocha actually loads all files first, that means that all code written before the hooks and the describe calls is executed. So when the second file is loaded, the require.cache is already full of modules. Only after that the suite executes the tests sequentially.
That has a huge impact in this Framework because many objects are actually Singletons, so if in a after hook it closes a connection with a database, it closes the connection inside the Singleton. The way the Framework was built makes it very hard to give a workaround to this problem, like reconnecting to all services in the before hook.
I wrote a very ugly code that helps me before I can refactor the Framework. This goes in each test file I want to invalidate the cache.
function clearRequireCache() {
Object.keys(require.cache).forEach(function (key) {
delete require.cache[key];
});
}
before(() => {
clearRequireCache();
})
It is working, but seems to be very bad practice. And I don`t want this in the code.
As a second idea I was thinking about running Mocha multiple times, one for each "module" (as of my Framework) or file.
"scripts": {
"test-integration" : "./node_modules/mocha/bin/mocha ./api/modules/module1/test/integration/*.integration.js && ./node_modules/mocha/bin/mocha ./api/modules/module2/test/integration/file1.integration.js && ./node_modules/mocha/bin/mocha ./api/modules/module2/test/integration/file2.integration.js"
}
I was wondering if Mocha provides a solution for this problem so I can get rid of that code and delay the code refacting a bit.
I've been looking around at somehow disabling console.log in my application while running unit tests, and I found answers that say you can override the console.log like this:
console.log = function(){};
I tried putting this in app.js, and it overrides console.log when I'm running the app, but not when running unit tests, so I tried adding it the to test file, but then it overrides mocha / chai's console.log, and I get a blank screen.
Is there a way to override the console.log in all files except the one running?
What you would probably want to do instead is use a logging library like Loggly or Bunyan. With these you pass the message you want to log to the client and then you can output those logs based on the environment you are in. In your case you want to log during production but not during testing (kindof odd, but whatever). So you would set process.NODE_ENV to dev or prod accordingly and the logger would take care of the logging for you. Here's an overview of some loggers.
I am new to node and what I would call, real server-side programming (vs PHP). I was setting up a user database with MongoDB, Mongoose and a simple mongoose user plugin that came with a schema and password stuff to use. You can add validation to Mongoose for your fields like so
schema.path('email').validate(function (email) {
if (this.skipValidation) return true
return email.trim().length
}, 'Please provide a valid email')
(this is not my code). I noticed though when I passed an invalid or blank email, .trim() failed and the entire server crashed. This is very worrisome to me because things like this don't happen in your good ol' WAMP stack. If you have a bug, 99.9% of the time it's just the browser that is affected.
Now that I am delving into lower level programming, do I have to be paranoid about every incoming variable to a simple function? Is there a tried-and-true error system I should follow?
Just check before using the variable with trim, if it is !null for example:
if(!email) {
return false;
}
And if you want to run your app forever, rather use PM2.
If you are interested in running forever, read this interesting post http://devo.ps/blog/goodbye-node-forever-hello-pm2/
You may consider using forever to keep your node.js program running. Even it crashes, it restarts automatically and the error is logged as well.
Note: Although you could actually catch all exceptions to prevent the node.js from crashing, it is not recommended.
One of our strategies is to make use of Node.js Domain to handle errors - http://nodejs.org/api/domain.html
You should set up a error logging node modules like Winston, once configured produces useful error/exceptions.
Have a look in this answer for how to catch error within your node implementation, though specific to expressjs but relevant.
Once you catch exceptions, it prevents unexpected crashes.
I'm looking for a way to output Node variables directly into the google chrome browser console. The same way a console.log() works on the client side. Something like this for php. This would greatly speed up development.
NOTE:
Since the old answer (written in september 2014) refers to an older version of node-inspector, my instructions are not relevant anymore in 2017. Also, the documentation has gotten a lot better, so I have updated my original answer:
node-inspector is what you need.
It opens up an instance of Chrome with its developer tools for debugging.
It's also easy to use:
1. Install
$ npm install -g node-inspector
2. Start
$ node-debug app.js
Source: https://github.com/node-inspector/node-inspector
You might want to try NodeMonkey - https://github.com/jwarkentin/node-monkey
I know it's an old question but came on top of my Google search so maybe somebody will find my answer useful.
So you can use node --inspect-brk index.js
Now, all you have to do is basically just type chrome://inspect in your Chrome address bar and click Open dedicated DevTools for Node
In DevTools, now connected to Node, you’ll have all the Chrome DevTools features you’re used to:
Complete breakpoint debugging, stepping w/ blackboxing
Source maps for transpiled code
LiveEdit: JavaScript hot-swap evaluation w/ V8
Console evaluation with ES6 feature/object support and custom object formatting
Sampling JavaScript profiler w/ flamechart
Heap snapshot inspection, heap allocation timeline, allocation profiling
Asynchronous stacks for native promises
Hope that helped.
The closest thing to this I've seen is Node JS console object debug inspector
See this post for usage and potential issues: http://thomashunter.name/blog/nodejs-console-object-debug-inspector/
For users with nodejs on linux via ssh-shell (putty):
Problem with nodejs on linux-ssh-shell is, that you have no browser connected.
I tried all this solutions, but didnt get it to work.
So i worked out a solution with firebase (https://firebase.google.com), because my project uses firebase.
If you are familiar with firebase, than this is a great way. If not, firebase is worth using in combination with nodejs - and its free!
In the server-side-script (started with node) use a own function log():
// server-side:
// using new firebase v3 !
var fbRootRef = firebase.database();
var fbConsoleRef = fbRootRef.ref("/console");
var log = function(args) {
fbConsoleRef.set({'obj': args});
}
// inside your server-code:
log({'key':'value'});
On client-side you create a firebase-reference on this console-object:
// client side:
fbRootRef.child('/console').on('value', function(d) {
var v = d.val();
console.log(v);
});
Now everything logged on server-side with the log() - function is transferred in realtime to the firebase-database and from there triggering the client-console-reference and logged into the browsers console.
If anyone needs help, i will explain in more detail and could give a more extended version of this logging with types (console./log/warn/info), grouping with title-info (i.e. server says: (filename + line).
Setting up firebase for your project is done in max 30 minutes, inserting the console-function in 30 minutes. I think its worth the time!
You can use bonsole, a simple way to log something in browser. Even in Linux, you can go to the LAN's ip to check it.
The most simple way with least dependencies is using a WebSocket connection to send the messages to the browser. Any WebSocket example you can find on the internet will suffice to accomplish this. Everything else requires to be heavily integrated into the host system and wouldn't work if you want to actually run this on a remote server. You can also send commands to the server directly from the browser console this way.
Links:
https://www.npmjs.com/package/websocket
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications