Allows writing lint-friendly tests #297

joshperry · 2014-10-13T22:39:04Z

This makes the final assertion checks noop functions so that they can be formatted like function calls. This keeps linters (JSLint/JSHint) off our back for having an inop expression.

Fixes #41

This makes the final assertion checks noop functions so that they can be formatted like function calls. This keeps linters (JSLint/JSHint) off our back for having an inop expression. Completes chaijs#41

bajtos · 2014-10-14T07:09:12Z

The solution is much simpler and nicer compared to what I was originally imagining. Great job!

keithamus · 2014-10-14T09:56:43Z

@joshperry this change looks great! Thanks for working on this. Could you please also add some documentation around the methods, so that users can discover this feature (for example the documentation here: https://github.com/prodatakey/chai/blob/noopchainfunc/lib/chai/core/assertions.js#L178-L191)

logicalparadox · 2014-10-14T13:16:06Z

lib/chai/assertion.js

@@ -69,6 +69,10 @@ module.exports = function (_chai, util) {
    util.addChainableMethod(this.prototype, name, fn, chainingBehavior);
  };

+  Assertion.addChainableNoop = function(name, fn) {
+    util.addChainableMethod(this.prototype, name, function() { }, fn);


You should create the NOOP function as a file-wide variable and only reference it here.

I don't disagree... The only thing I'm wondering is, do we want to document this method for use by plugin authors? If so, perhaps we should just make a more idiomatic function for chainable assert terminators. addChainableAssertion maybe?

keithamus · 2014-10-24T14:31:31Z

Any progress @joshperry? It'd be sweet to see some added documentation, and @logicalparadox's suggestion implemented. Then we can look toward merging 😄

joshperry · 2014-10-24T14:37:53Z

I am out of the country on vacation, I should be back somewhere that I can wrap this up by the middle of next week. Cheers!

keithamus · 2014-10-24T14:39:14Z

Apologies @joshperry. Enjoy your vacation!

joshperry · 2014-11-04T16:58:23Z

Was just writing up some documentation and wondered what you guys thought about having an optional message parameter on these functions like its siblings have (e.g. equal, above, etc...).

expect('everthing').to.be.ok();
expect(everything).to.be.ok('Everything was not ok');

bajtos · 2014-11-04T17:03:32Z

As far as I am concerned, I can already specify the message via expect(what, message), so I don't need the other option. Although I can image the feature may be useful for should users.

However, I would appreciate so much if this PR got landed as soon as possible, and extra bells and whistles were left for later, for a different PR.

My two cents.

joshperry · 2014-11-04T17:18:42Z

@bajtos Agreed.

This wouldn't really work with the current assertion execution setup anyway. The assertion is thrown on property access and the function never gets called to set the message. If we wanted to provide a message parameter, there would need to be a substantial refactor of these assertions.

logicalparadox · 2014-11-04T17:24:39Z

@joshperry In addition to the documentation can you also write a snip for the ReleaseNotes that explains the impact of this change. You can see a previous example here. You can just post it as a comment here and I will make sure it makes it into the release notes when I publish. Thanks!

Furthermore, FYI, this will be tagged as release v1.10.0

joshperry · 2014-11-04T17:26:08Z

Added some docs... Seems repetitive, but wasn't sure what else to put.

@logicalparadox Definitely

joshperry · 2014-11-04T18:16:54Z

No Op Function for Terminating Assertion Properties

The below list of assertions are property getters that assert immediately on access. Because of that, they were written to be used by terminating the assertion chain with a property access.

expect(true).to.be.true;
foo.should.be.ok;

This syntax is definitely aesthetically pleasing but, if you are linting your test code, your linter will complain with an error something like "Expected an assignment or function call and instead saw an expression." Since the linter doesn't know about the property getter it assumes this line has no side-effects, and throws a warning in case you made a mistake.

Squelching these errors is not a good solution as test code is getting to be just as important as, if not more than, production code. Catching syntactical errors in tests using static analysis is a great tool to help make sure that your tests are well-defined and free of typos.

A better option was to provide a function-call form for these assertions so that the code's intent is more clear and the linters stop complaining about something looking off. This form is added in addition to the existing property access form and does not impact existing test code.

expect(true).to.be.true();
foo.should.be.ok();

These forms can also be mixed in any way, these are all functionally identical:

expect(true).to.be.true.and.not.false();
expect(true).to.be.true().and.not.false;
expect(true).to.be.true.and.not.false;

The following assertions can now also be used in the function-call form:

ok
true
false
null
undefined
exist
empty
arguments
Arguments

Plugin Authors

If you would like to provide this function-call form for your terminating assertion properties, there is a new function to register these types of asserts. Instead of using addProperty to register terminating assertions, simply use addChainableNoop instead; the arguments to both are identical. The latter will make the assertion available in both the attribute and function-call forms and should have no impact on existing users of your plugin.

keithamus · 2014-11-05T11:01:49Z

lib/chai/core/assertions.js

@@ -185,12 +185,17 @@ module.exports = function (chai, _) {
   *     expect(false).to.not.be.ok;
   *     expect(undefined).to.not.be.ok;
   *     expect(null).to.not.be.ok;
+   *     expect(null).to.not.be.ok;


This looks to be a duplicate line.

keithamus · 2014-11-05T11:07:09Z

I have a few points which I'd personally like to see wrapped up on this:

The tests assert like .to.be.ok, .to.be.ok() and .to.be.ok().and.be.true but I'd also like to see tests that do .to.be.ok.and.be.true()
The documentation says "Can also be used in function form which will satiate certain linter errors." for each of the methods - but I worry about the term 'satiate' for EFL speakers. I'd like to see this reworded as "Can also be used as a function, which prevents some linter errors".

With both of those fixed, plus my above comment about the duplicate line, I'd be very happy with this and would happily merge it in, pending @logicalparadox's veto.

joshperry · 2014-11-05T14:31:53Z

Thanks for the input, @keithamus.

Agreed on both points. I added a few unit tests exercising the form in your first point and revised the wording in the docs.

keithamus · 2014-11-05T16:39:34Z

@logicalparadox I'm happy with this, I can merge if you're happy.

@joshperry Thanks for putting the effort in, looks great!

lo1tuma · 2014-11-05T19:41:02Z

@joshperry thanks for your work, this is awesome.

logicalparadox · 2014-11-09T01:54:30Z

👍

abenhamdine · 2014-11-09T14:29:46Z

Kudos !
Can't wait to have this patch.
Is it planned to be in 1.9.3 or in 1.10 ? Have you planned a release date for the next version ?

Thanks for all, folks.

Allows writing lint-friendly tests

keithamus · 2014-11-10T09:44:23Z

🎉

keithamus · 2014-11-10T09:44:46Z

@abenhamdine to quote @logicalparadox:

Furthermore, FYI, this will be tagged as release v1.10.0

logicalparadox · 2014-11-10T14:13:53Z

Release 1.10.0...

https://github.com/chaijs/chai/blob/master/ReleaseNotes.md#1100--2014-11-10

bajtos · 2014-11-10T16:00:09Z

AWESOME! 🙇

abenhamdine · 2014-11-10T20:44:04Z

✌️

elliotf · 2015-02-05T00:11:23Z

I just found this and wanted to say thank you to @joshperry .. developers on my team have had issues when learning the assertions library and done things like expect(foo).to.exists; (or somesuch) not realizing that exists is not an actual assertion. Tests didn't fail because no assertion was being made. With this change, they'll get an error saying so, as long as they call it as a function!

Thank you!

More details chaijs/chai#297

joshperry added 2 commits October 13, 2014 16:31

Allows writing lint-friendly tests

4b0c0b6

This makes the final assertion checks noop functions so that they can be formatted like function calls. This keeps linters (JSLint/JSHint) off our back for having an inop expression. Completes chaijs#41

Change test to not trigger argument bug

cc1357d

logicalparadox reviewed Oct 14, 2014
View reviewed changes

Make the NOOP function a shared constant

9142ce0

Add docs for function style NOOP asserts

bbd3aaf

joshperry force-pushed the noopchainfunc branch from df2b2f4 to bbd3aaf Compare November 4, 2014 17:27

joshperry force-pushed the noopchainfunc branch from a04ed74 to bbd3aaf Compare November 4, 2014 18:49

joshperry mentioned this pull request Nov 5, 2014

Add lint friendly assertions chaijs/sinon-chai#48

Closed

keithamus reviewed Nov 5, 2014
View reviewed changes

joshperry added 2 commits November 5, 2014 07:25

Revise documentation wording

c448e1d

Add unit tests for chained terminating property asserts

b4c0424

Add a couple more unit tests

867563b

keithamus added a commit that referenced this pull request Nov 10, 2014

Merge pull request #297 from prodatakey/noopchainfunc

828f481

Allows writing lint-friendly tests

keithamus merged commit 828f481 into chaijs:master Nov 10, 2014

keithamus mentioned this pull request Nov 13, 2014

Revert "Allows writing lint-friendly tests" #306

Merged

keithamus mentioned this pull request Nov 26, 2014

Allow .true() assertion to use an optional message #272

Closed

keithamus mentioned this pull request Dec 10, 2014

"#<Assertion> is not a function" using assertions as functions in nodeJS #321

Closed

johanneswuerbach mentioned this pull request Feb 5, 2015

chaijs 1.10 allows to write lint-friendly tests ember-cli/ember-cli-mocha#35

Closed

johanneswuerbach added a commit to johanneswuerbach/ember-mocha that referenced this pull request Feb 5, 2015

chaijs 1.10 allows to write lint-friendly tests

d1cba18

More details chaijs/chai#297

johanneswuerbach mentioned this pull request Feb 5, 2015

chaijs 1.10 allows to write lint-friendly tests emberjs/ember-mocha#13

Closed

johanneswuerbach added a commit to johanneswuerbach/ember-mocha that referenced this pull request Feb 5, 2015

chaijs 1.10 allows to write lint-friendly tests

2f75240

More details chaijs/chai#297

keithamus mentioned this pull request Feb 12, 2015

Get a proper changelog #366

Closed

keithamus mentioned this pull request Feb 19, 2015

breaking change in 2.0 (null, undefined, arguments, ok, true, false, empty, exist) #371

Closed

keithamus mentioned this pull request Mar 23, 2015

Make assertions (such as .exist) callable #56

Closed

bajtos mentioned this pull request Apr 23, 2015

Chai-like "expect" API shouldjs/should.js#60

Closed

keithamus mentioned this pull request Nov 9, 2015

Test passes when the thing after "to.be" is nonsense #549

Closed

This was referenced Nov 24, 2015

Throw for non existent properties or language chains #557

Closed

expect(...).to.be.ok and .to.be.defined/undefined etc should be able to take custom Assertion Error messages #558

Closed

meeber mentioned this pull request Apr 25, 2016

ok() is not a function #690

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allows writing lint-friendly tests #297

Allows writing lint-friendly tests #297

joshperry commented Oct 13, 2014

bajtos commented Oct 14, 2014

keithamus commented Oct 14, 2014

logicalparadox Oct 14, 2014

joshperry Oct 14, 2014

keithamus commented Oct 24, 2014

joshperry commented Oct 24, 2014

keithamus commented Oct 24, 2014

joshperry commented Nov 4, 2014

bajtos commented Nov 4, 2014

joshperry commented Nov 4, 2014

logicalparadox commented Nov 4, 2014

joshperry commented Nov 4, 2014

joshperry commented Nov 4, 2014

keithamus Nov 5, 2014

keithamus commented Nov 5, 2014

joshperry commented Nov 5, 2014

keithamus commented Nov 5, 2014

lo1tuma commented Nov 5, 2014

logicalparadox commented Nov 9, 2014

abenhamdine commented Nov 9, 2014

keithamus commented Nov 10, 2014

keithamus commented Nov 10, 2014

logicalparadox commented Nov 10, 2014

bajtos commented Nov 10, 2014

abenhamdine commented Nov 10, 2014

elliotf commented Feb 5, 2015

Allows writing lint-friendly tests #297

Allows writing lint-friendly tests #297

Conversation

joshperry commented Oct 13, 2014

bajtos commented Oct 14, 2014

keithamus commented Oct 14, 2014

logicalparadox Oct 14, 2014

Choose a reason for hiding this comment

joshperry Oct 14, 2014

Choose a reason for hiding this comment

keithamus commented Oct 24, 2014

joshperry commented Oct 24, 2014

keithamus commented Oct 24, 2014

joshperry commented Nov 4, 2014

bajtos commented Nov 4, 2014

joshperry commented Nov 4, 2014

logicalparadox commented Nov 4, 2014

joshperry commented Nov 4, 2014

joshperry commented Nov 4, 2014

No Op Function for Terminating Assertion Properties

Plugin Authors

keithamus Nov 5, 2014

Choose a reason for hiding this comment

keithamus commented Nov 5, 2014

joshperry commented Nov 5, 2014

keithamus commented Nov 5, 2014

lo1tuma commented Nov 5, 2014

logicalparadox commented Nov 9, 2014

abenhamdine commented Nov 9, 2014

keithamus commented Nov 10, 2014

keithamus commented Nov 10, 2014

logicalparadox commented Nov 10, 2014

bajtos commented Nov 10, 2014

abenhamdine commented Nov 10, 2014

elliotf commented Feb 5, 2015