Comments (7)
You will notice the error type when this occurs is not an AssertionError, but a regular Error.. L569.
It didn't fail because the assertion failed, it failed because the pretenses of the test were insufficiently prepared and therefor outside of chai's ability to pass judgement. As such, I think the appropriate response is to inform the developer of this.
Make sense? Thoughts?
from chai.
As I see it, there are two equivalent interpretations of expect(o).to.have.property(p, v)
and its negation:
- As an extension of
expect(o).to.have.property(p)
, i.e. as a logical conjunction of two conditions: P ∧ P', where P =o[p] !== undefined
and P' =o[p] === v
. In which case the negation of this assertion,expect(o).not.to.have.property(p, v)
, should be defined by ¬ (P ∧ P'), or by De Morgan's, ¬P ∨ ¬P'. And since ¬P1 =o[p] === undefined
is true if o does not possess property p, the negative assertion should pass. - As simply
o[p] === v
. In which case the negation iso[p] !== v
, which if o does not possess property p, is equivalent toundefined !== v
, which also passes.
In neither case is chai unprepared to pass judgement as I see it. Maybe you can elaborate on your thinking?
from chai.
Very logical arguments. I applaud your use of De Morgan's law! However, the point of the expect
and should
interfaces is to provide a natural language interface. I see that there are three possibly ways that your statement could be written in natural language...
expect('asd').to.not.have.property('foo', 3);
// 1. "I expect asd to not have the property `foo`, and assert that `foo` should equal 3."
// 2. "I expect asd to not have the property `foo`, and assert that `foo` should not equal 3."
// 3. "I expect asd to have the property `foo`, and assert that `foo` should not equal 3."
- This makes absolutely no sense. I cannot test the value of something I expected to not exist. Will always fail.
- This is your approach. You are negating both statements. Even if you logically get past the fact that I am testing the value of something I expected to not exist, foo will never equal 3, or anything for that matter. So why didn't you just
expect('asd').to.not.have.property('foo')
if you wanted to assert that the property doesn't exist? By your logic, will always pass. - This is the current approach. Given what we have just seen, the logical assumption is that since a value of
3
was provide,foo
was expected to exist. This will not pass as the expectation of having the property does not pass, or, stated...
It didn't fail because the assertion failed, it failed because the pretenses of the test were insufficiently prepared and therefor outside of chai's ability to pass judgement. As such, I think the appropriate response is to inform the developer of this.
from chai.
Actually, #2 is not my approach. My approach is: "I expect that either asd does not have property foo
, or that it does, but not with the value 3." That's the logical negation.
I believe it is least surprising if the assertion "X should Y" succeeds exactly when the assertion "X should not Y" fails, and vice versa. It's simple, predictable, and how negation works in every assertion library I've seen prior to chai. Though now I've looked and it seems should.js and expect.js both have this quirk as well, so perhaps I'm on the losing side in that regard.
As for the third interpretation, I would write such an assertion as expect('asd'.foo).not.to.equal(3)
. It's more succinct and leaves no room for misinterpretation.
from chai.
I'm not sure I like 'either' as an approach in this testing scenario. I don't like that a single assertion could pass for two separate scenarios. Especially where there is multiple interpretations of how the language chain should operate, Its better to throw and force the user be more succinct.
A hazard of working with language chaining assertion libraries... but perhaps it's a curtesy in the long run.
from chai.
I am going to close this issue. At this time, compatibility with similar libraries (expect/should) makes chai more accessible to new users wanting to migrate.
As far as the debate of logics go, shall we call it a stalemate for the time being? ;)
from chai.
👍 I'm struggling to write a .to.redirectTo(url)
assertion that makes sense.
Ideally, expect({ statusCode: 301, headers: { location: 'foo' }}).to.redirectTo('foo')
and expect({ statusCode: 200 }).not.to.redirectTo('http://example.com')
should both pass.
I'm attempting to compose this assertion from chai-http
status and header assertions, but having lots of trouble De Morganizing those sub-assertions. For now I've settled for expect({ statusCode: 200 }).not.to.redirectTo('http://example.com')
failing. Seems in line with this discussion but unsatisfying.
from chai.
Related Issues (20)
- ERR_REQUIRE_ESM in v5 HOT 41
- v5 vs chai-as-promised HOT 1
- [v5] `assert.isFunction()` fails with async function HOT 4
- v5 - `Unknown file extension ".ts"` when running with mocha HOT 11
- mutating chai exports no longer works in v5 HOT 22
- Add support for Promise HOT 16
- SyntaxError: Invalid or unexpected token HOT 1
- [email protected] syntax error in assertion.js:69 HOT 2
- NPM README and GitHub README don't match
- @types/chai seems not to be adapted to version 5.0.0 HOT 9
- Documentation revamp HOT 3
- please provide commonjs exports again HOT 5
- Migrating to Chai 5.0 in browser
- use() function only returns plugin first time HOT 1
- assert.throws() does not work correctly in node/vm spawned context HOT 5
- TypeError: Unknown file extension ".ts" with Chai 5.0.0 and later HOT 2
- chai-spies broken in v5.1.0 HOT 1
- The plugin API makes me want to murder someone
- without "@types/chai" my IDE didn't recognize some attributes
- chai-subset is unmaitained HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chai.