Have promise rejection tests mirror how Chai tests exceptions.

[lddubeau]

This PR takes care primarily of #47. I've also dealt with #64 and #113 while working on this.

Some notes on this PR...

This PR introduces a bunch of breaking changes. There's no way around it if our goal is to have .should.be.rejectedWith and assert.isRejected mirror what Chai does with should.throw and assert.throws.

Notably:

• .fulfilled, .rejected and .rejectedWith now change the object flag when they are successful. Code relying on the old behavior will fail, or in some cases it could be successful but not test what it used to test. Code that used chaining with these assertions should be hand-inspected and modified as needed.

• .not.rejectedWith now has different semantics. In previous versions foo.should.not.be.rejectedWith(Constructor, 'string') would fail if the error was rejected with an instance of Constructor. If it was rejected with an instance of Constructor then the next parameter would not even be inspected. It would also fail if the error was rejected with an instance of something else that had for message 'string'.

  This was different from how foo.should.not.throw(Constructor, 'string') has been behaving in Chai. In Chai, this test would fail only if the error thrown is an instance of Constructor and if it has the message 'string'. A Constructor instance with a different message would not cause a failure. An instance of a different class with the message 'string' would not cause a failure.

  Tests that were failing will now pass due to this change. All instances of .not.rejectedWith need inspection to see whether they need to be modified in light of the new semantics.

While fixing #113 I've done the following:

• .fulfilled, .not.rejected and .not.rejectedWith when successful:
  • The promise they return is fulfilled with the same value as the promise they were testing.
• When .not.fulfilled, .rejected and .rejectedWith are successful:
  • The promise they return is fulfilled with the rejection reason.

In all cases, when they fail, the promise they return is rejected and has for reason the assertion that failed.

The changes above make it so that (as mentioned before) the object flag is automatically set when the promise returned is resolved, and thus also allows chaining. (I've tested chaining independently.)

I have flip-flopped on whether the eventually flag should be automatically set by .fulfilled .rejected and .rejectedWith. If it is set, then the tests that follow forcibly pertain to the fulfilled value of the promise they return. If it is not set, then if the user wants to test the fulfilled value, they have to use .eventually. Otherwise the tests are done on the promise itself.

The one thing that I don't like about not setting the eventually, it is really easy to end up not testing what one think they're testing. One may write this:

promise.should.not.be.fulfilled.and.have.property("nonexistent")

When one means to write this:

promise.should.not.be.fulfilled.and.eventually.have.property("nonexistent")

The first will check that the promise returned by fulfilled does not have the property nonexistent. The second checks that the rejection reason does not have the property nonexistent.

Using check-error turned out to be a bit problematic.

Chai passes check-error to plugins as the checkError field on the utils parameter. However, no version of Chai has been released yet that has this field on utils. (Probably the next version after 3.5.0 would do it. Note that I've tried running chai-as-promised with the latest master of Chai and got a whole slew of errors. Fixing chai-as-promised to work with Chai@master is beyond the scope of my task.) It seems to me making chai-as-promised require that future version as a minimum peer dependency would be too restrictive.

In the code proposed here, chai-as-promised now does this: if utils.checkError exists, use that. Otherwise, it use an instance of check-error loaded from the module system (or obtained globally
when chai-as-promised is loaded through script).

[domenic]

Wow, thank you so much!!

I'm at a week-long conference this week, so I'll be a bit slower in reviewing than I would like. But I will try to carve out time during the nights to work on this. Hopefully we should be able to merge by end of the week.

[domenic]

I merged this with no changes, just to the commit messages :). I also then did a subsequent commit to remove the UMD stuff and just go with CommonJS. A new major version will be going out shortly. Thank you so much for your help!