truncateThreshold should apply to more types or the documentation should be clarified

The docs on truncateThreshold currently state:

config.truncateThreshold
    @param {Number}
    @default 40
User configurable property, sets length threshold for actual and expected values in assertion errors. If this threshold is exceeded, the value is truncated.

Set it to zero if you want to disable truncating altogether.

chai.config.truncateThreshold = 0; // disable truncating

The first statement is not strictly true because truncateThreshold only applies to objects, arrays and functions. For example:

chai.config.truncateThreshold = 10;
chail.assert.equal('fooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo', 'foo');

// Results in:
AssertionError: expected 'fooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo' to equal 'foo'

[keithamus]

The plan is for loupe (our inspection lib) to truncate intelligently, based on the actual and expected. So if you had a trunaceThreshold of 10 the string foobarbazbing would render as 'fooba...', but if you compared foobarbazbing to foobazbingbar then the error message would be more like Expected '...ar...' to equal '...az...' (obviously 10 is not a very practical truncate threshold but it illustrates the point of showing only the differences).

The idea behind this is that truncateThreshold will A) really truncate to the specified length and B) give you better, richer, more relevant information when truncated.

Edit: It should also be pointed out that there is still a lot of figuring out on how to do this the right way, and we’ll be making sure we don’t end up making error messages less usable - just removing crufty information that is not needed.

[lucasfcosta]

Hi @Joris-van-der-Wel, thank you very much for this issue! 😄

Recently we have been adding our priorities to a roadmap board and referencing issues there to make sure we’ll get things done in a better and more organised way.

Your suggestion is much appreciated and we’ll certainly take it into account when refactoring loupe.

For now, I’ll close this in order for us to get a clean slate to work on.

Thank you very much!