Format extra level of extraneous / missing complex items when depth limit is reached

Question

Format extra level of extraneous / missing complex items when depth limit is reached

novemberborn opened this issue 6 years ago · comments

Complex items are often not understandable without seeing their properties or (if they're lists or iterables) nested items. If the depth limit is reached we should still format an extra level, so rather than

  [
+   Object { … },
    Object { … },
  ]

we could print:

  [
+   {
+     id: 'first',
+   },
    {
      id: 'second',
    },
  ]

We'll have to consider whether this is a violation of the "max depth" concept. I have a feeling we already do this elsewhere though.

Printing all items at an extra level may be unnecessary.

IssueHunt Summary

bunysae has been rewarded.

Backers (Total: $60.00)

issuehunt ($60.00)

Submitted pull Requests

#62 Reset depth when formatting differences

Tips

Checkout the Issuehunt explorer to discover more funded issues.
Need some help from other developers? Add your repositories on IssueHunt to raise funds.

Nick Heiner · Answer 1 · Thu Jul 05 2018 00:11:46 GMT+0800 (China Standard Time)

Based on my use case in avajs/ava#1850: it may be that it's actually really hard to come up with logic for depth limits that produces usable results for all cases. It may be easier to give the user a bit more control rather than trying to always guess correctly.

Mark Wubben · Answer 2 · Thu Jul 05 2018 01:05:25 GMT+0800 (China Standard Time)

Yea I realize that. This particular feature may be a new classification of "depth", and perhaps the configuration option here should take an object for each classification. Then consuming libraries can set their preferred values.

Speaking for AVA, I don't think we'd want the depth to be configurable. With the right defaults, the occasional full-depth-formatting could be done with t.log().

Tim Ruffles · Answer 3 · Tue Jul 24 2018 23:12:19 GMT+0800 (China Standard Time)

@novemberborn hi Mark :D Been a while since State.com

I realise this issue touches on multiple repos/decisions etc, but I'm finding it a pain how large/complex objects end up getting formatted. I currently see ~550 lines of output for simple checks on, for instance, Sinon properties (the use of ava+sinon is fixed by my client):

  `subscribe` handles API error if `api.subscribe` call is unsuccessful
   172:
   173:     t.true(api.subscribe.calledOnce);

  Value is not `true`:

  false

  api.subscribe.calledOnce
  => false

  api.subscribe
  => Function proxy {
    addBehavior: Function {},
    alwaysCalledOn: Function {},
...
    },
  }

If there was a way to control this (perhaps I've missed one?), e.g

t.simple.true(...)

or

import { format } from 'ava'
format.prototype(sinon.Spy.prototype, { ... })

I'd be very happy.

Mark Wubben · Answer 4 · Thu Jul 26 2018 15:59:54 GMT+0800 (China Standard Time)

@timruffles 👋

I think in Sinon's case, the answer is to support a plugin that disregards those API methods from the comparisons and formatting.

Or maybe Sinon can mark them as non-enumerable? Not sure how that works with proxies.

daniel-livestories · Answer 5 · Tue Jan 29 2019 01:46:29 GMT+0800 (China Standard Time)

Speaking for AVA, I don't think we'd want the depth to be configurable. With the right defaults, the occasional full-depth-formatting could be done with t.log().

This is one of the reasons I'll be abandoning AVA. When my tests fail, why do I need to go out of my way to understand why they failed? This is testing, please be very, very verbose. Or at least give me the controls to always be very, very verbose.

IssueHunt Bot · Answer 6 · Sun Jun 09 2019 13:26:26 GMT+0800 (China Standard Time)

@issuehunt has funded $60.00 to this issue.

Submit pull request via IssueHunt to receive this reward.
Want to contribute? Chip in to this issue via IssueHunt.
Checkout the IssueHunt Issue Explorer to see more funded issues.
Need help from developers? Add your repository on IssueHunt to raise funds.

Bunyanuch Saengnet · Answer 7 · Thu Mar 19 2020 00:50:52 GMT+0800 (China Standard Time)

@novemberborn
What you think about the idea rendering just the diff completely and the other properties with the max depth level like this?

[
+   {
+     id: 'first',
+   },
     Object { … },
  ]

It would handy for investigation and doesn't overwhelm developers too much. This behavior could be activated with a new configuration option.

Pedro Augusto de Paula Barbosa · Answer 8 · Thu Mar 19 2020 02:05:08 GMT+0800 (China Standard Time)

@bunysae That might be a good idea, but what if the extra object has ten levels of depth? Maybe some sort of compromise should be used here...

Bunyanuch Saengnet · Answer 9 · Thu Mar 19 2020 02:38:26 GMT+0800 (China Standard Time)

Spoken in the case of ava, the best compromise would a parameter passed to ava-cli. If this parameter is omitted, the default depth-level can be used. For example:

npx ava --depth 1 for max. one depth-level,
npx ava --depth 2 for max. two depth-levels,
...
npx ava --depth f for full-depth-formatting
npx ava with the defaults
Then it is up to the user finding the correct depth-level and it wouldn't violate the existing behavior.

Mark Wubben · Answer 10 · Sun Mar 22 2020 22:14:55 GMT+0800 (China Standard Time)

What you think about the idea rendering just the diff completely and the other properties with the max depth level like this?
[
+   {
+     id: 'first',
+   },
     Object { … },
  ]
It would handy for investigation and doesn't overwhelm developers too much.

@bunysae I like it!

Then it is up to the user finding the correct depth-level and it wouldn't violate the existing behavior.

AVA follows Node.js' printing depth, see https://github.com/avajs/ava/blob/master/docs/06-configuration.md#object-printing-depth.

issuehunt-oss · Answer 11 · Sun May 17 2020 20:14:43 GMT+0800 (China Standard Time)

@novemberborn has rewarded $54.00 to @bunysae. See it on IssueHunt

💰 Total deposit: $60.00
🎉 Repository reward(0%): $0.00
🔧 Service fee(10%): $6.00