Better example of testing interaction in a React.js component

input-test.js

/*
I think this is a better example of interaction testing, because the component has its own
internal function, which a) does more than one thing, and b) has a small amount of logic
where it plucks the new value out of the DOM event. Those we can test in isolation.
*/
const MyInput = props => {
  const handleChange = event => {
    props.updateTheValue(event.target.value);
    props.fetchSomeDataThatDependsUponTheValue();
  };
  
  return <input type="text" onChange={handleChange} value={props.value}/>;
}

MyInput.propTypes = {
  value: React.PropTypes.string.isRequired,
  updateTheValue: React.PropTypes.func.isRequired,
  fetchSomeDataThatDependsUponTheValue: React.PropTypes.func.isRequired
}

describe('MyInput', () => {
  it('emits the new value when it changes, and causes a fetch of some data that depends upon the new value', () => {
    const updater = jasmine.createSpy();
    const fetcher = jasmine.createSpy();
    const myInput = shallowRender(<MyInput updateTheValue={updater} fetchSomeDataThatDependsUponTheValue={fetcher}/>);
    
    myInput.props.onChange({ target: { value: 'new value!' } });
    expect(updater).toHaveBeenCalledWith('new value!');
    expect(fetcher).tohaveBeenCalled();
  });
});

/*
Where the example potentially expands even further, is if the component's internal function
only calls the callback props under certain conditions. E.g. you might have a handleBlur
inside the component, which can check if the value has actually changed, and will only call
a callback if it has. You could test that by reaching into the props and manually calling
onBlur with different event values, and check whether or not the input callbacks are invoked.
*/

I really don't see this as a great deal of change, and does it work since you call props.onChange which I can't see is defined. Or will myInput.props.onChange trigger the onChange on the input field? If it does I think this is what you want to do, if it doesn't you can continue reading :).

Text below assumes that myInput.props.onChange doesn't reach the onChange of the input field:

Since try to call the props function directly you could as well do it without the component, since everything you test is or could as well be defined outside of the component.

const handleChange = event => {
    props.updateTheValue(event.target.value);
    props.fetchSomeDataThatDependsUponTheValue();
  };

could, or maybe even should(?), be provided as a single prop to the component instead of two props.

To really test the component, when you're doing it as stateless as you do, I do think you want to test the actual wiring of the component, that is, when you edit/change/update that field your function mapped to props get called. If you don't do that and just call the props function directly you could as

In case you're not aware of how shallow rendering works, what you get back is the React element (not component) that's returned by the component when it gets rendered.

So in this case, myInput is just an object that tells you what props and children were given to the <input> element. So to answer your question regarding myInput.props.onChange():

• Yes, doing this will call whatever function was passed as the onChange prop of the <input> React DOM element - this ensures that the correct behaviour is bound to the onChange prop. Good!
• No, it won't create a 'real' <input> DOM node and simulate a DOM event. This test will pass if your component does whenChange={handleChange}, as long your test has the same mistake - myInput.props.whenChange();. Bad!

You're right that the kind of logic I've shown here can be pulled out of the component. In fact for stateless components that don't have exclusive access to any information, it's probably true that all callbacks can be bound directly to action creators, rather than having these internal functions with a small amount of logic. At the moment I don't really have a strong feeling either way on that.

However, if you go in that direction, where all DOM events are bound directly to action creators, with no interaction behaviour contained within the component, then I don't think there's anything worth unit testing there. If you want more confidence that everything is hooked up correctly (e.g. you haven't typo'd a DOM event name), then I would try to cover that off with a test higher up the testing pyramid - either an integration test that uses renderIntoDocument and Simulate from the React TestUtils, or a UI test using something like Capybara. In practice though, I don't think I've seen any bugs creep through because of this sort of mistake.

Thoughts?

Thank you for clarifying the shallow rendering part, then all is good :). This would actually have the test on the "level" I think I want them.