I'm not a big fan of TDD, I believe you should at least know what you are coding and be able to run the code and verify the outputs by yourself prior to merging it. TDD somehow takes away this responsibility from the programmer in my opinion. However, I do advocate for E2E tests, as they are more broad and written from the point of view of the application user, and probably will be written by someone else rather than the one who actually coded that piece of software that's being tested.
Having them both in a project would be ideal, but if I have to choose - and more often than not I have to, because deadlines - I believe E2E produces more results at a lower time investment. But that's just a feeling, I have no numbers unfortunatelly. What do you think?
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.
I'm not a big fan of TDD, I believe you should at least know what you are coding and be able to run the code and verify the outputs by yourself prior to merging it. TDD somehow takes away this responsibility from the programmer in my opinion. However, I do advocate for E2E tests, as they are more broad and written from the point of view of the application user, and probably will be written by someone else rather than the one who actually coded that piece of software that's being tested.
Having them both in a project would be ideal, but if I have to choose - and more often than not I have to, because deadlines - I believe E2E produces more results at a lower time investment. But that's just a feeling, I have no numbers unfortunatelly. What do you think?
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.