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)
- sdhdshdh
- Deen
- TypeError: util.addProperty is not a function HOT 1
- `fail(message)` creates misleading test output
- `isAtLeast()` creates misleading output
- Links Broken HOT 3
- Allow deepEqual to use a custom comparator HOT 4
- Unclear description in official docs creating spy: 'ee.on' ? 'some event' ?
- chai.version field is incorrect HOT 8
- Potential Security Vulnerabilities Detected in Package
- Mention existence of `5.x.x` branch and `v5.0.0-alpha.0` in README HOT 2
- `chai.should()` break error reporting in `node:test` on node `18.17.0`
- 5.0.0-alpha.1 was published as "latest" npm dist-tag HOT 2
- strictEqual / deepStrictEqual behave differently on numbers
- Vulnerability in chai Module HOT 2
- Fix get-func-name HOT 3
- Update dependency on `get-func-name` to at least 2.0.1 to fix CVE HOT 5
- Buffer is not recognized as an object HOT 1
- Officia type definitions for 5.x? HOT 6
- Package subpath './register-should' is not defined by "exports" in node_modules/chai/package.json for node 18.14.0 HOT 1
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.