I need to start this by saying that TDD is a very powerful technique that helps.

This is a discussion of the areas not to test.

Don’t fully test a library. Do have a test that the library does what you need.

Don’t build integration tests when you are unsure about the specific implementation ( especially if the setup becomes excessive). Add the tests on the second feature.

When integrating with 3rd party APIs you may get more value instrumenting well and seeing hoe it behaves in production. This is the source of the “don’t mock what you don’t control” rule. Vendors rarely provide an accurate test environment. REPLs are the best way to experiment with them.

If you have complex logic (more than one if statement or a trivial reduce) then write tests for that. They will be easy to write now and will be valuable as things become more complicated.

https://storybook.js.org/docs/6.5/react/get-started/why-storybook/

This is a tool that allows you to isolate UI components. The practical benefit is that you can list all of the expected states of a component without having to build the world around it.

I am currently working on displaying data that has no simple way of recreating accurately in environments below production. By using Storybook I can demonstrate what it would look like.

Another benefit is that you can test the component in isolation on a range of devices/browsers. That makes checking a new component much easier.

Larger organisations try to adopt a Domain Driven approach where various parts try to act independently.
This is a good plan.

However independence does not mean ignoring other parts of the business that are consumers of what you produce.

Domain Driven Organisations need clear defined boundaries between the various domains. If the boundaries (contracts between systems) are weakly defined then changes in one place can have an impact in an ideally unrelated system.