Manjula Dube

He doesn’t know what he is up to but he is trying to do productive testing :)

Productive testing means testing right things in the react app. By which I mean the correct thing that makes sense to test. Remember when you write test cases its not to make your coverage results get the higher attention but to write test so that app functionality works correctly and its easier to refactor the code and you don’t break the code while refactoring. How easily you can refactor your code matters the most because thats what the developer is hired for :)

When it comes time to actually write the tests though, we often get stuck. What exactly should you test? It can be hard to tell when or why to test your app, too.

So, here are a few reasons why testing done right is productive. As you read the article may be you will realise that you are not testing the correct way & you if you don’t that means you already know the stuff.

Why you write tests is a question, but let me answer it for you 👇

The main reason to write tests is to ensure that your app works the way it should. That’s really it. The trouble comes when you define “works the way it should” to be very, very your own way (which means you end up testing all bits and pieces) and then testing all of your methods & , to the point of checking link that hovers to testing the static text. This is simply not worth testing and its just waste of time.

Stop doing that please.👆

Test things that makes sense

What not to test ?

# Don’t test if some method is called or not (It doesn’t make sense)

# Don’t test what’s inside the state

# Don’t test your lifecycle methods

Kent C. Dodds said “You should take a step back and pretend that all you can do with the component is interact with it in the way the end-user will interact with it or the way a typical developer would render it (passing props etc.)”

Not testing implementation gives you confidence in both, the app and the tests. I’ve did end up writing lots of implementation specific tests and found them seldom helpful. I mean, yes, the code was covered, but I always broke the tests every time i made changes to my code. And then I was like “May be lets just not write tests at all”

One of question by Vivek Nayyar to Kent C. Dodds was:

Should we be testing if a certain click that caused setState has updated the state or not like how we do it enzyme’s update() method and state() method?

And here’s his answer

No, those are implementation details. Think about what the observable behavior of clicking that button will be. When I click the button, state will be set, the component will be re-rendered, and a message appears or whatever. Just check that the message appears and you’re good.

What to Test?

Here are some general guidelines for what’s worth testing about a React component.

It must render: At the very least, make sure the component renders without error. This verifies there are no JSX syntax errors, that all variables are defined, etc. This could be as simple as verifying that the rendered output is not null.

Test the output: Test if renders correct thing with correct props.

Test the states: Test every conditions. If the classNames are conditional (enabled/disabled, success/warning/error, etc), make sure to test that the className-deciding logic is working right. Likewise for conditionally-rendered children. If some button is only visible on certain conditions.

Test the events: If the component can be interacted with (an input or buttonwith an onClick or onChange or event), test that the events work as expected and call the specified functions with the correct arguments.

Test the edge cases: Anything that operates on an array could have boundary cases — an empty array, an array with 5 element, a paginated list that should truncate at certain number of items, and so on. Try out every edge case you can think of, and make sure they all work correctly.

I test for what happens there, like if a fetch happened. Or something like this. But never directly or spying for it or anything. said @**Alexander Plavinski**

In short , test the implications rather than testing implementation details in the components. Also do not test random stuff (like implementation) just increase you coverage report. Because if you do that may be you will have an awesome coverage reports but you will break the tests every time you refactor your code.

TEST LIKE A PRO SO YOU CAN REFACTOR LIKE A BOSS!!

Test it the right way. Your coverage report will be awesome naturally :)

I ended up writing this blog just after after a quick discussion on what should we test on twitter. Thanks to Kent C. Dodds for sharing his views :)

Also if you want to get into testing this is best thing ever at the moment. Testing JavaScript with Kent C. DoddsThis course will teach you the fundamentals of testing your JavaScript applications using eslint, Flow, Jest, and…testingjavascript.com

Thanks for reading !!!

If you are interested in testing and want to know more about it. You can even reach out to me :)