Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge rebased 4.x.x branch into master #783

Merged
merged 19 commits into from
Sep 10, 2016
Merged

Conversation

meeber
Copy link
Contributor

@meeber meeber commented Sep 5, 2016

I ran into one minor issue while rebasing the 4.x.x branch:

There was a test in the 4.x.x branch that relied on being able to access an Assertion object's flags after the assertion had failed and been caught in a try/catch block. However, a change in the master branch made it so that assertions return a new Assertion object with flags transferred over, instead of returning the original Assertion object. This means that any subsequent flags are set on the new Assertion object instead of the original. For a successful assertion, this is fine, since the new Assertion object is returned. But in this case, for a failed assertion that throws an error and is caught in a try/catch block, the test no longer has access to any of the failed Assertion object's flags that were added after the first step in the assertion.

I resolved this issue in an extra commit that fixes this broken test by getting rid of the .to chain so that the test has access to the relevant Assertion object and its flags.

In addition to the issue above, I made a couple of side notes:

  • A few tests broke in Node v6.5 due to a change in how anonymous functions that are assigned to a variable appear in failed assertion error messages. This issue is completely unrelated to 4.x.x. I'll be following up this PR with a separate one that addresses that.
  • There's now a large divergence between the behavior of the .property and .ownProperty assertions due to heavy refactoring of .property in master and minor refactoring of .ownProperty in the 4.x.x branch. I'll be following up this PR with a separate one that addresses that.

(Closes #772)

@keithamus
Copy link
Member

This looks like some truly great work @meeber. LGTM, tagging @lucasfcosta for the merge.

Also interesting to see how much of 4.0 has been driven by @lucasfcosta - looks like many commits in that PR. Congrats on the stellar work, both of you!

@meeber
Copy link
Contributor Author

meeber commented Sep 6, 2016

@keithamus Thank you sir, and agreed regarding Professor Lucas's contributions. Most of them were made before I joined the team, so this was my first time reviewing them. Unsurprisingly, they were excellent commits across the board! And everything was well-documented, so I was able to understand and resolve all conflicts during the rebase. Thank you @lucasfcosta!

@lucasfcosta
Copy link
Member

Yay! I'm happy to hear that! Thank you so much guys!
Actually, you are the ones who are awesome, I could not have made those commits without your help. Your ideas and reviews were essential to guarantee the quality of that work.
I said that yesterday on twitter, but I'd like to repeat it: I learned a lot by reading your code and comments.
I'll use my time this weekend to look at this with attention and make sure everything is okay.

Thanks for the work Mr. @meeber and Mr. @keithamus! It's an honor to be a part of this great team!

@@ -679,14 +684,15 @@ module.exports = function (chai, _) {
/**
* ### .least(value)
*
* Asserts that the target is greater than or equal to `value`.
* Asserts that the number target is greater than or equal to `value`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a merge, but I'll just leave this here as a note:
Shouldn't it be written Asserts that the **target number** ... instead of Asserts that the **number target** ...?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the reason it was phrased that way is because that's how it was already phrased elsewhere in the code (see: #692 (comment)). I think the thing for us to do is submit a separate PR that rephrases all of them (both old and new) at once.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahhh, I remember that now!
Thanks for refreshing my memory!
I totally agree with you, that would be a great idea, I will open an issue for that just so we won't forget.

*
* expect(10).to.be.at.least(10);
*
* Can also be used in conjunction with `length` to
* assert a minimum length. The benefit being a
* more informative error message than if the length
* was supplied directly.
* was supplied directly. In this case the target must
* have a length property.
*
* expect('foo').to.have.length.of.at.least(2);
* expect([ 1, 2, 3 ]).to.have.length.of.at.least(3);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another side note here:

Currently we can't do:
expect([ 1, 2, 3 ]).to.have.a.length.of.at.least(3);
Because the a word returns a function which has a property called .length and there is no way we can remove that in some environments, but we could use a Proxy in environments that do support it to override what happens when trying to access length on the function returned by addChainableBehavior, what do you think? Is this possible? I didn't dig deep on this one, but I think it might be a valid strategy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, because function.length is configurable in modern environments, it can be intercepted with proxies or manually deleted without the use of proxies. I think one of them is worth doing (in a separate PR) but I'm not sure which approach is best.

@lucasfcosta
Copy link
Member

I just went through it all and it LGTM!
Excellent work @meeber (as you always do)! 😄
I left a couple of minor non-merge-related notes of things that should be done after this PR gets merged.

@meeber
Copy link
Contributor Author

meeber commented Sep 10, 2016

@lucasfcosta Thanks for the careful review! I think this is ready to merge. Do you want to do the honors? :D

@lucasfcosta
Copy link
Member

@meeber Yes! Of course, I haven't seen @keithamus already approved this, thanks for noticing!

HERE WE GO!
Pushing the red button!

@lucasfcosta lucasfcosta merged commit 8166f33 into chaijs:master Sep 10, 2016
@meeber
Copy link
Contributor Author

meeber commented Sep 10, 2016

@lucasfcosta Superb use of Ren and Stimpy gif.

@lucasfcosta
Copy link
Member

Thanks @meeber, it took years of practice 😄

@meeber meeber deleted the 4.x.x branch August 6, 2017 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Merge 4.x.x branch into master
6 participants