Jest stalls after comparing to complex objects

[sebmarkbage]

(version v15.1.1)

In this PR, I can't use expect(a).toBe(b); on two complex and cyclic objects. It works fine if the test pass but if the test fails I think it tries to print/report the object structure or something. Interestingly enough it works fine on some of the other similar objects.

The end result is that jest stalls and doesn't print or proceed with anything else. I thought it might have been an infinite loop but if I run it with the Chrome debugger in Node 6 I can't stop. There's no break point so it seems like the event loop is just paused waiting for new messages that never arrive.

[chase]

@sebmarkbage It looks like the original commit that caused this failure was dropped during a history rewrite.

I checked out your fork and went to the next similar commit at sebmarkbage/react@f904163, then replaced the originally problematic line in src/renderers/shared/fiber/tests/ReactTopLevelFragment-test.js

    ReactNoop.flush();

    var instanceC = instance;

-    expect(instanceC === instanceA).toBe(true);
+    expect(instanceC).toBe(instanceA);
  });

When running jest at master (commit 2e36e25), the test fails but does not stall. I doubt that this is comparing the correct object, because the expected and received values are both null.

This is the output of the test: https://gist.github.com/chase/cc980da37005dc0d48bed7b3cdd9f4d5

It might be fixed in jest@master now, but I don't have access to the original commit where it broke.

[sighrobot]

(react 15.3, jest-cli 16.0)

This happens consistently when I expect(instance).toBeNull() when instance is in fact not null.

[gaearon]

I can reproduce this with a simple test:

it('hangs', function() {
  var elem = document.createElement('div');
  expect(elem).toBe(undefined);
});

It hangs forever on Jest 16.0.1.

[quantizor]

@cpojer any idea if you guys will be able to get to this soonish? Keeps coming up for my team and tracking down the culprit assertion is not always easy.

[cpojer]

It's faster if you send a PR! Unfortunately I've been pretty backed up with a ton of work.

[quantizor]

Hmm, ok I'll try and make time to look into this tomorrow.

[chase]

I did a little digging and it seems that @sebmarkbage's analysis was right.
Large or cyclic objects when passed to prettyFormat causes the cli to stall as the maximum depth is Infinity by default.

I will put in a basic PR tomorrow morning that at least deals with the symptoms mentioned, but I think that a long term solution would be to limit the verbosity or object depth being printed with a CLI option to adjust it.

[quantizor]

Fix submitted to pretty-print jamiebuilds/pretty-format#47

[quantizor]

Downgrade to jest-cli@15 if you want to avoid this bug until it's addressed.

[chase]

@yaycmyk, thanks for putting in the effort for HTML element printing. I'm sure your hours of work won't go to waste.

I got pulled for some crunch time tasks and ultimately got distracted from my pull request.
@cpojer, I forgot to ask: would the test be a better fit as an integration test? Seems like there's no easy option to use jsdom for a package's unit test as they all default to node for the testEnvironment.

[cpojer]

Sure, that's fine too.