User Experience (navigating to another page) should be done with end-to-end like Cypress.

If you have a button with a link that has a dynamic url that has some logic you need to test that logic/url in your unit test. But not the behavior.

I would validate a form, not a field. If your test is to big it's probably because your form is to big.

e2e tests are easier to write and find more bugs. You should start with those first. Those are more difficult to get started with if your app requires user authentication. But once you solve that problem with your tests, e2e is a better pay-off

Once you've got e2e tests that hit at least every page on your site, and every http call that it makes, component tests now fill in the gaps for your testing. They're more difficult to write, but not by a lot. They don't catch as many bugs, since e2e tests will catch not only frontend bugs, but backend bugs (if a data model changed on the backend, or it's suddenly throwing a 500, for example). But, they allow you to your components a little more carefully. They also run a lot faster than e2e tests. I use to have over 10 boxes running in parallel on GitHub actions for a few hundred e2e tests. You really don't need to bother with parallel boxes for component testing.

Stubs/Mock everywhere is a terrible idea, it makes you produce thousand of lines of code that will test itself instead of testing your application in real condition.

Why is it a terrible idea to stub everywhere? Normally if you use a proper stubbing framework, that shouldn't take thousands of line of code. There are certainly cases where mocking isn't the right approach, but most of the time it's OK in my opinion.

The goal of unit testing is not to deal with "real" cases, that's what E2E and integration testing is for. With unit testing you try to test a specific piece of API, and to do that, you often try to abstract all its dependencies by stubbing them.

The "just say no more to E2E tests" mentions a 70/20/10 rule. The reasoning behind this is that writing E2E tests is time consuming. If you would E2E test everything, developing might take 2 times longer than it would without. But as usual, it's about finding the right strategy. Not writing E2E tests has its implications as well.

About the RxJS code, since you're talking bout a HTTP call and transforming the data, I would stub Http and write 2 unit tests:

• One that makes sure that the call to Http is made correctly. So in your case you would be sending your JWT token with it?

• One that retrieves the result. You can subscribe to your observable in your test and test the response that comes from it.

You may want to verify how to properly write tests with asynchronous code though. You don't want your test to end before you actually receive a value from your observable.