Unit test a React Render Prop component
In this lesson, I use Enzyme and Jest to unit test a Counter Render Prop component. Writing integration tests are perfect for components that consume a Render Prop component. Likewise, unit tests are important to write for the Render Prop component itself, as you can test each individual unit that makes up the component.
Instructor: [00:00] I have a simple render prop component for a counter I'd like to unit test. The component accepts an initial value, has state, has two methods for incrementing and decrementing. I passed all these things to the render prop function, which has children in this instance.
[00:14] This render prop component is considered renderless because it doesn't actually render anything to the dom. But it holds the state and logic for other components to consume.
[00:22] We should test those other components that consume this with integration tests. But it's a good idea to thoroughly test your render prop component itself. Let's do that. For this example, I'm going to use enzyme ingest for testing. But can use whatever your heart desires as long as it asserts.
[00:36] The first thing I'm going to do is test that the render prop function gets called on mount. I'll use Jest to mock a function that returns null. We'll do that by writing const render function equals Jest function mock return value null.
[00:52] Next, we'll need to mount our counter and pass our mock function to it. Let's do it by const wrapper equals mount. Pass the counter to it. We'll say render function.
[01:03] The first assertion that we'll make is that the render function has been called. We'll say expect render function mock call's length to be one. For good measure, I'll go ahead and test our state, as well. We'll say expect wrapper state counter to be zero. Check our test. Looks like it's passing.
[01:26] Onto our next test. We'll go ahead and copy this. We'll test the initial value. We'll say accepts an initial value. We'll go ahead and pass an initial value to our counter. We'll adjust our assertion here to say our counter state should be 2,012. Save it. Check our test. It looks like it's passing. Good.
[01:50] Next, we'll copy our test again. We'll test our first method which is increment. We'll just say increments. I'll remove our initial value since we don't need that. I'll manually invoke our increment method, wrap our instance, increment. Now to adjust our assertion. We'll say to be one. Save it. Check our tests. Looks like they're passing.
[02:14] Now, I'll go ahead and copy this, change this to be decrements, invoke our decrement method, and change this to negative one. Save it, check our tests. All of our tests are passing.
[02:27] Remember, it's a good idea to thoroughly test your render prop component, especially if you're publishing a library that others may consume. Integration tests are great for components that consume render prop components like this. But having unit tests can help you cover your bases...
Thanks for the lesson. I found it very useful :)
There is no point of testing implementation details, that's why I think asserting the state value is not a good idea.
I agree in some cases Mykolas. My example is kind of contrived because all of the methods just update the state. The main point for unit testing a Render Prop (or component in general) is to test all of the methods as units. Some of them may not effect state and could contain advanced logic you want to make sure is correct.
I have Render Prop components that offer many different methods and my consumer components only take advantage of a few of them at a time, so when I write integration tests I am usually only testing a few of those methods by interacting someway with the consumer component. Unit testing the Render Prop component itself is good because you can test every unit in isolation.
Testing this stuff has a wide spectrum so everyone has their thoughts. I appreciate yours! thanks for watching.
Thanks for the lesson. I found it very useful :)
Thanks for watching Steve! Glad it helped!
There is no point of testing implementation details, that's why I think asserting the state value is not a good idea.