Nested Property Chainability

[jakemingolla]

The chaining of .nested.property using .and does not follow what I would expect compared to other expectations:

// test.js
'use strict';
const expect = require('chai').expect;

const foo = 5;

// Passes
expect(foo)
  .to.be.above(4)
  .and.to.be.below(6);


const bar = {
  baz: {
    first: [ 1, 2, 3],
    second: 'Hello!'
  }
};

// Fails
expect(bar)
  .to.have.nested.property('baz.first')
  .and.to.have.nested.property('baz.second');

$ node test.js

/Users/jmingolla/Documents/dev/node_modules/chai/lib/chai/assertion.js:141
      throw new AssertionError(msg, {
      ^
AssertionError: expected [ 1, 2, 3 ] to have nested property 'baz.second'
    at Object.<anonymous> (/Users/jmingolla/Documents/dev/chai-test/test.js:22:23)
    at Module._compile (module.js:573:30)
    at Object.Module._extensions..js (module.js:584:10)
    at Module.load (module.js:507:32)
    at tryModuleLoad (module.js:470:12)
    at Function.Module._load (module.js:462:3)
    at Function.Module.runMain (module.js:609:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:598:3

Unless I am misreading the documentation, it would appear that nested property expectations return the actual value at that field rather than the original object. Is this intended?

[meeber]

@jakemingolla Yup, it's intended behavior. One alternative (other than breaking your assertion into multiple assertions) is to use .include, although this would require providing expected values as well:

expect(bar).to.deep.nested.include({
  'baz.first': [1, 2, 3],
  'baz.second': 'Hello!',
});

[jakemingolla]

@meeber Thanks, that makes sense. It would be cool if the target value was dependent on the context of the chained command (i.e. .and referring to the current target, .that referring to the target of .nested.property)

[keithamus]

We've discussed this before in a few flavours (the general issue being "flags are permanent"), most recent of which is #785

[keithamus]

We're using Chai 5 as an opportunity to re-evaluate all decisions, including the chaining one. It's very likely we'll come up with something that can fill this gap. Probably by dropping chaining and implementing something in the shape of what #644 describes.