npm test returns "connect ECONNREFUSED"

1,541 views
Skip to first unread message

Jef Harkay

unread,
Jan 31, 2014, 4:49:15 PM1/31/14
to expre...@googlegroups.com
I'm trying to test my app, and it always returns an error of connect ECONNREFUSED.  I made a simple example to show what's happening.  Here's my controller (CompoundJS code):


load('application');

action('getTest', function() {
  var obj = {success: true, data: 'blah'};
  send(obj);
});

action(function show(data) {
  var http = require('http');
  var options = {
    path: '/getTest',
    port: process.env.PORT  // without this, http fails because default port is 80
  };
  var req = http.get(options, function(res) {
    var data = '';
    res.on('data', function(chunk) {
      data += chunk;
    });
    res.on('end', function() {
      data = JSON.parse(data);
      return send(data);
    });
  });
  req.on('error', function(e) {
    return send({success: false, data: e.message}); // returns "connect ECONNREFUSED"
  });
});

So when I have the app running, I can hit /test (which is the show method there) and /getTest just fine without any errors.  However, when I try to run the following test code, I get the error as stated above, and the issue comes down to that http.get, as I can get into the show function just fine.

var app, compound
  , request = require('supertest')
  , sinon = require('sinon');

function TestStub() {
  return {
  };
}

describe('TestController', function() {
  beforeEach(function(done) {
    app = getApp();
    compound = app.compound;
    compound.on('ready', function() {
      done();
    });
  });

  /*
   * GET /test
   */
  it('should render "index" template on GET /test', function(done) {
    request(app)
      .get('/test')
      .end(function(err, res) {
      console.log(res.body);
      done();
    });
  });

});


Any ideas on how to fix this?

greelgorke

unread,
Feb 3, 2014, 2:30:44 AM2/3/14
to expre...@googlegroups.com
looks like either the server doesnt run or you hit a wrong port. i don't see any listen calls in your tests.

btw. there is a compound group too

Jef Harkay

unread,
Feb 5, 2014, 9:22:57 AM2/5/14
to expre...@googlegroups.com
Well, the server is running because it hits the first endpoint show, but then it doesn't hit the getTest endpoint, so I'm assuming this is an issue with testing.  The interesting thing is, if I run the server and then run the tests, it works fine, but I don't want to have to do that every time I want to do testing.

I posted in the Compound group as well, but because I believe this isn't a Compound issue, but more of a Node/unit testing issue.

greelgorke

unread,
Feb 6, 2014, 5:25:56 AM2/6/14
to expre...@googlegroups.com
Its not a node thing, it's how your application and supertest works. since your just pass the app to supertest and never calls listen in your test yourself, supertest does it for you and binds your server on random port. in your /test action you do a get request against another action and assume the right PORT in environment. but this port is different from the port supertest uses for the testrun. this is why your http.get fails. its the wrong port.

how you can fix this? the dirty variant is to determine the currently used port as supertest does here https://github.com/visionmedia/supertest/blob/master/lib/test.js#L57-L62

but the better solution is to not to http.get yourselfes actions. Unless you have verry unusual infrastructural considerations, its just inefficient and, as you can see, errorprone. if your ap is a single mashine thing, then just call the function, you passed as action:

load('application');

function getTest(cb) {

  var obj = {success: true, data: 'blah'};
  if(cb) return cb(null,obj)
  else return send(obj);
}

action('getTest',getTest);


action(function show(data) {
  var http = require('http');
  var options = {
    path: '/getTest',
    port: process.env.PORT  // without this, http fails because default port is 80
  };
  getTest( function(err, res) {
     //do your thing
  });
});

if you want to loadballance this, then use load ballancers, cluster or apache/nginx etc.

so far my opinion.
Reply all
Reply to author
Forward
0 new messages