That's the reason why we have two kinds of tests: unit tests for the individual components, and integration test for the whole package. To resemble the way your software is actually going to be used, you should focus and stress on the latter.
The former (unit tests) just ensures that the component doesn't break on its own, its only really helpful in large orgs where multiple teams develop their components separately and the build or devops team then integrates the whole thing.
If you are a solo dev who does both backend and frontend, it'd make sense to combine them, the integration test is the unit test for you, doing it separately will simply be a waste of time.
Yep. I think we're discussing the difference between 'acceptance tests' and 'unit tests' - as Uncle Bob calls them.
I think 'front end' (not meant as a derogatory term!) devs tend not to think about unit testing as being worthwhile. Part of that is probably because there aren't as many layers in the front end 'project' structure as there usually is in the back end. In the back end I hope you'd expect both unit tests and acceptance tests, but if there aren't any complicated functions that need unit testing, maybe the acceptance tests are enough.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.