When Does Code Need To Be Tested?

dylanesque profile image Michael Caveney ・1 min read

I've heard that testing should be based on application behavior and how users interact with the product, which makes sense. What's extremely unclear to me is when is a feature obviously working to the point where you don't need to test it? For example, I see why testing the results of an API call is important even if manually testing it in Postman/Insomnia/the browser yields expected results. But I'm confused by something like testing of what gets rendered in React. How do you decide what portions of your code need to be tested?


Editor guide
stemmlerjs profile image
Khalil Stemmler

In Uncle Bob's book, "The Clean Coder", he says that everything should be tested.

Although, he goes on to say that writing tests for front-end presentational code like the stuff we do in React are non-ideal because it's the most susceptible for change.

I used to test all my front end code with Cypress and other E2E tools, but those tests are incredibly flimsy because as soon as the selectors are altered in any way, the tests break. You spend a lot of time updating tests for front-end code. Generally speaking, my opinion is that it isn't worth it.

Instead, you want to test the things that don't change that often. Things that aren't that volatile, like the features.

For example, if you were to test a Login Page, how would you go about doing that? It's a pretty important page to ensure that it works. What would you do?

You could test against the input fields and whatnot, but as soon as we want to change the style, there's a chance we might break those integration tests.

What's a better way to test the feature or Logging in?

Through the API. Because it's a lot less likely to change.

In "The Clean Coder", Uncle Bob recommends us to refrain from testing volatile things like the views, and instead test that the features work through the API calls.

If you have time, writing Cypress tests and testing the view is nice, but your entire goal is to reduce the amount of testing "implementation details" (a div was used here, and a span with color: green was used here), and instead test the "business rules".

The testing of backend code is a lot easier to understand the principles of writing testable code in my opinion.

devkevyn profile image

Check "behaviour driven development".

This type of testing mindset states that you only need test the business requirements (a higher abstraction of the code) that actually add value to your stakeholders. It doesnt remove unit testing or 100% coverage testing, but it helps prioritize which code to test.

I could go on but read about it. It's a good place to start

scriptmunkee profile image
Ken Simeon

All of the previous answers are good, but still theoretical. Here is my perspective as a Software Quality professional and what I expect developers to test.

1 Test that your feature / bug fix / etc meets the defined acceptance criteria
2 Test any and all logic paths created/updated during development
3 If building UI features / components, do a sanity test across different browsers (i.e. IE)

With the three points above and considering your final question. To me it means you'd test the combination of components produced by React (manually or automated). If you are creating dynamic components based on specific data or behavior, then that is a logical path that should be tested. If the result of the logic path is a React component, then you can write automated tests that validate the component was actually generated.

dylanesque profile image
Michael Caveney Author

I want this framed in needlepoint on my wall, this is a really good approach!

scriptmunkee profile image
Ken Simeon

Hahahaha πŸ˜‚thanks!

alanmbarr profile image
Alan Barr

There are different risks you might be concerned with and the closer to the logic you can get with tests typically the cheaper it is to create a test and verify it works. When you start combining applications, modules, state the territory you need to cover to verify things work becomes expensive to write and maintain. If you're working in marketing and your main goal is generating leads you might be pretty tolerant of various bugs because as long as the leads flow things are good. However, if you don't have testing around the leads and that goes down for hours that could be significant revenue loss and investing in testing infrastructure in that space makes sense.