As devs, we’re taught to write tests first, then refactor until the tests pass. This is difficult if you don’t know your design first and frustrating if you have the functionality, but the tests aren’t passing.
Which is why, if you write your code to where it can be tested easily, everyone wins.
Using Functional Programming vs. Class-based components
The concept is not new. Writing functions vs. classes is much more efficient. While you can easily instantiate a class and have everything you need, they are hard to test when it comes to React. Breaking just about everything into functions and utilities allows your code to be tested with ease and code coverage is boiled up using abstract methods vs complex classes.
Maps, ForEach, other loopy things? Use a function for that, too.
Unless the operation is super simple, define a named function for what happens within a map() or forEach() loop which can be isolated and tested.
Quality over Quantity
It’s super easy to pad code coverage these days. Just test to see if something mounts without breaking and tada! You’ve got super high code coverage…but what did you test, really? TOD expects that your tests should be value over volume. If you have a lot of code that flows through a small area or maybe you already have methods that are shared throughout your code base. Start there. If there’s one small break in that code, it will wreck the most.
Quality Multiplied
Now that we a test that adds value over volume, what other scenarios can we throw at it. Don’t settle for just one scenario. Cover multiple. Got several test cases you want to iron out? Write a function for it and make your tests DRY.
Top comments (0)