Duplicating Node.js `assert` assertions in spec `expect`

Tested code is heavily packed with Node assert assertions with reasonably meaningful message arguments.

module.exports = class Some {
  constructor(arg) {
    assert.deepEqual(['foo'], 'Some constructor arg')
    ...
  }
}

Current spec may look like that:

it('...', () => {
  let some = new Some(['foo']);
  expect(some).to...

To cover all the logic it may be even

it('...', () => {
  const { AssertionError } = require('assert');
  let some = new Some(['foo']);
  expect(some).to...
  expect(() => new Some(['bar']).to.throw(AssertionError);

So we basically assume here that half of testing job was already done in the code itself with assert and skip the details (to.not.throw and matching AssertionError messages).

The example above use Mocha+Chai, but the same thing applies to Jasmine.

• Should app assertions be doubled with spec assertions with 'to throw', 'to not throw', and AssertionError message matching, what are the circumstances of doing the opposite?

• Can test coverage tools (Istanbul) take into account assert assertions in app code in addition to expect?

• May test runners be confused by the fact that it was app, not spec assertion that threw an error?

Some examples of successful open-source JS projects that prove or refute 'assert assert assertions' point in practice could be also helpful.