It always depends a little bit on what you're actually doing. I generally tend to prefer TDD. However, you can also distinguish between the inside-out or outside-in approach. In the outside-in approach, you would - similar to what you describe - first write the E2E tests and then implement the functionality with the help of unit tests. You have a two-level loop, so to speak:
Write E2E test. Watch it FAIL.
Step down to a Red-Green-Refactor cycle with unit tests to implement necessary functionality.
Step back up and rerun E2E test. Watch it PASS (hopefully).
I can understand how this might seem to slow you down. It certainly will in the beginning. In the long run, however, the added security ensures that you can make changes with confidence. In addition, you think a bit more about the design before you implement something. This can also have many advantages.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It always depends a little bit on what you're actually doing. I generally tend to prefer TDD. However, you can also distinguish between the inside-out or outside-in approach. In the outside-in approach, you would - similar to what you describe - first write the E2E tests and then implement the functionality with the help of unit tests. You have a two-level loop, so to speak:
I can understand how this might seem to slow you down. It certainly will in the beginning. In the long run, however, the added security ensures that you can make changes with confidence. In addition, you think a bit more about the design before you implement something. This can also have many advantages.