-
Notifications
You must be signed in to change notification settings - Fork 46.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Shallow Testing #2393
Comments
Basic shallow rendering support (#2393)
Reopened so that we can track the remaining features (refs etc.) |
Weird, I thought GitHub only closed issues if you used language like "fixes #NNNN", not if you simply mentioned the issue at all. Sorry about that. |
The PR text included "WIP to fix #2393." |
Is the rest (refs support) blocked by #1373 or can more work be done now? @sebmarkbage |
Any reason this doesn't support var shallowRenderer = ReactTestUtils.createRenderer();
var instance = shallowRenderer.render(<SomeComponent />);
var result = shallowRenderer.getRenderOutput();
expect(result.type).toBe('div');
instance.handleClick(); // will call setState inside
result = shallowRenderer.getRenderOutput();
expect(result.type).toBe('span'); // imagine it returns <span> with different state |
@gaearon, that's supposed to work. Can you post a minimal repro? |
It works if I use |
Finding this quite useful. But it has been a bit inconvenient to have |
The idea was to make the |
@sebmarkbage Really? Allowing nulls was a change intentionally introduced a long time ago. In #3650 I have an implementation of toArray. |
Allowing empty children (null, undefined, boolean) was a controversial topic, where we eventually landed on null/boolean/undefined being passed through. That way you could explicitly treat an empty slot as something special. This landed very early on before we really started seeing pattern developing. However, IMO, we've seen that this leads to inconsistent implementations where null slots will break and is not possible to use. It is unclear whether a set of children allows nullable slots, and if they do, it is unclear what that means. For example, in a grid layout component, does an empty slot mean that there should be an empty column in the grid, or that it should be skipped? Therefore, a lot of our components end up with explicit null checks. Meaning boilerplate, and inconsistent behavior when they're forgotten. Therefore, I think the default should be to filter out nulls which is consistent with the behavior of the built-ins components. It is still possible to get access to the raw data if you have a different type of children in mind where empty slots is meaningful. |
How should this work with the TestUtils functions. For example, this fails: shallowRenderer.render(<Section />);
reactModule = shallowRenderer.getRenderOutput();
let mySidebar = reactModule.props.children[1].props.children[0];
expect(mySidebar.props.className).to.equal('sidebar'); // Yep
let mySidebars = TestUtils.scryRenderedDOMComponentsWithClass(reactModule, 'sidebar'); // Also tried reactModule._instance...
expect(mySidebars.length).to.equal(1); // Nope I can't see any other info on My end goal is simply to test that if I pass in 10 articles then 10 components get rendered. Any help would be awesome. |
Hi David, the
|
Cool, thanks for the reply @graue. I've returned to just using |
So, I am trying to use Shallow Rendering and have it mostly working...the only thing left I can’t figure out is the recommended way to mock events and how to get Source code: |
If I have an issue with shallow rendering, should I create a new issue, or post it here? |
New issue please. |
@trevordmiller you might find that https://github.com/glenjamin/skin-deep helps in providing higher-level assertions for the sort of thing you're doing there. In that particular case, I would avoid asserting on the event handler of the anchor in that test - but a different test would want to call |
@davidgilbertson Super late reply, but "scry" is a fancy word for "find". I'm not sure why we don't just use "find". Maybe to avoid confusion between the plural and singular forms, whose names would otherwise differ only by one "s". |
scry is because of legacy internal FB APIs. No reason. |
Like @trevordmiller I'm keenly on the lookout for a way to correctly unit test event handling in React code. Is there any documentation that anyone could point me to? I've looked at https://github.com/glenjamin/skin-deep but it didn't seem to have something that scratches my particular itch. Here's my scenario (cut down):
Where Problem looks like this:
I'd like to be able to assert that |
What you actually want is to assert that clicking interacts with the router. Pass in a fake context with a router mock (try Simon) then call Apologies for the brevity, on a phone. |
Hi @glenjamin, Thanks for responding. I'm not too clear on how to mock successfully when it comes to context. Digging through the source of
However this dies a death with:
Which makes me think I'm getting the context mocking wrong. Do you know how you successfully mock context with |
Are you using React 0.13? You're probably hitting the difference between parent & owner context. Skin deep has a wrapper that helps with this - there's a context example the test suite, but the short answer is to wrap your render in another function call and let skin deep set up the context. This problem should go away in 0.14 |
I am using React 0.13, yes. If I port to 0.14 this issue should resolve? I might give that a crack if that's the case (it is in RC after all) |
Problems with the upgrade. I have raised an issue. Will have to return to this later I think. |
I have written https://github.com/algolia/react-element-to-jsx-string and https://github.com/algolia/expect-jsx as companion tools when testing with shallow rendering. It gives you the ability to diff on JSX strings rendered instead of React element objects. |
Hi, I was wondering what was the state of:
How can we help make this happen if that's still planned? |
This issue is pretty stale so I’ll close it. If there are specific features you miss in the shallow renderer please create new issues with proposals on how they should work. Note that we added a new test renderer that is much more feature-complete. |
We need a way to test the output of a single level React component without resolving it all the way down to the bottom layer (whatever that is).
I'm thinking something like this:
Basically, this fix needs to go through the entire life-cycle of ReactCompositeComponent. It just needs to bail out whenever it would've continued rendering.
The text was updated successfully, but these errors were encountered: