assert.throws when throwing an object (not an Error) #62

Closed
abernier opened this Issue Nov 24, 2012 · 2 comments

Projects

None yet

2 participants

@abernier

Hi,

I want to test that my couchDB's validate_doc_update function rejects unidentifed users:

module.exports = function (newDoc, oldDoc, userCtx, dbCtx) {
  if (!userCtx || !userCtx.name) {
    throw {unauthorized: "Fuck off!"};
  }
}

I don't know tap very well, but I'm pretty sure I should use assert.throws:

tap = require('tap')

validate_doc_update = require('./validate_doc_update')

icognitoCtx = {
  db: 'foo'
  name: null,
  roles: []
}

tap.test('Reject unidentified users', function (t) {
  t.throws(
    function () {
      validate_doc_update({}, {}, icognitoCtx);
    },
    {unauthorized: "Go away!"},
    'should stay polite and tell you to go away (not to fuck off)'
  )
});

My problem is this test passes despite {unauthorized: "Fuck off!"} does not equal {unauthorized: "Go away!"}...

Looking at the code, it seems tap deals with Errors only, not objects like the ones couchDB likes, eg: {forbidden/unauthorized: 'message'}

Do you see any work around for this?

thank you

@isaacs
Member
isaacs commented Nov 24, 2012

Hm. Not at the moment, but I'd accept a patch to make it treat any non-Error object using assert.has(), so you can specify arbitrary fields.

@abernier

Well, I don't know tap enough for now in order to submit a patch.

If it can help someone else, here is my work around:

tap.test('Reject unidentified users', function(t) {
  var er;
  try {
    validate_doc_update({}, {}, incognitoCtx);
  } catch(e) {
    er = e;
  }

  t.ok(er, 'An error has been thrown');
  t.deepEquals(
    er,
    {unauthorized: "Go away!"},
    'should stay polite and tell you to go away (not to fuck off)'
  )

  t.end()
});
@isaacs isaacs added a commit that closed this issue May 23, 2015
@isaacs isaacs Handle expected non-Error objects from t.throws
Fixes #62

Comes with the unfortunate caveat that any 'extra' data passed to
t.throws (ie, '{skip:true}' and the like) requires that an expected
error be passed in.

While this is technically a breaking change, it's a very rare edge case.
In practice, almost no one ever uses (or knows about!) the diag object,
so it's probably fine.  If there's complaining, I'll revert in the next
patch and push a major bump.
1ba3835
@isaacs isaacs closed this in 1ba3835 May 23, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment