4 ms·

I can't get behind this. End to end tests are indeed important. But let's say you have an end to end test that covers A, B, C, D, E, and F. One day this test

I can't get behind this. End to end tests are indeed important. But let's say you have an end to end test that covers A, B, C, D, E, and F. One day this test stops working. Well, what's the culprit? A? B? C? D? E? F? If you had more granular tests in addition to the end-to-end tests, you'd know. Now, I agree there's a possible downside here. Maybe there comes a time when C and D are no longer being used. It might not be obvious and C and D could linger in the code base, with corresponding dead weight in the test suite. This is not ideal. However, I would rather have this than a tough-to-debug test failure.

arkh 7y ago
> Well, what's the culprit? A? B? C? D? E? F? I honestly don't care. I know this merge is not touching production. I could have all of A, B, C, D, E and F test suites working individually if they break when put together they are all bad. The developer have tests so they know exactly how to reproduce the bug. Time for them to earn their salary.
yabadabadoes 7y ago
I see this over and over also in organizations I work in and even have to fight it in my own behavior.. If you run an end to end test automation and it fails and then you are afraid or otherwise hesitant of doing the process manually you are out of touch with the system and probably missing the forest for the trees when you work on subsystems. While I would like to have better end-to-end tests, I know that I will have to fight more problems of getting too far away from how the system works.
andrewflnr 7y ago
> Well, what's the culprit? A? B? C? D? E? F? Probably, the one you just changed. How often is it really going to be that hard to debug?
- thfuran 7y ago
  I only changed L, which is nominally unrelated to all of those. You thought this was a clean, well-modularized codebase?
  - JohnBooty 7y ago
    You thought this was a clean, well-modularized codebase? Well, even if it's nice and clean A, B, C, D, E are each going to have their own dependencies!
- JohnBooty 7y ago
  If you change B and the A/B/C/D/E integration test breaks.... duh, it's obvious. Yes, that's easy. But A, B, C, D, E are each going to have their own dependencies. You could change X, Y, and Z and now the A/B/C/D/E integration test breaks. Which one was it? Or maybe you're super cautious and you only change Z. And now the A/B/C/D/E integration test breaks. Obviously it's Z. But how? Why? It's a four-developer team and you're only really familiar with R, S, T, U, V, W, X, Y, and Z. There's also the fact that unit tests serve as living, de facto documentation on how to actually use the classes. You can both use and iterate upon Z a lot faster and more confidently if it has its own tests.
- foobiekr 7y ago
  The overuse of overly granular services can make this pretty awful unless you've put event tracing in place. I mean, the obvious answer is don't do that, but this is the world people are embracing.

arkh 7y ago

> Well, what's the culprit? A? B? C? D? E? F? I honestly don't care. I know this merge is not touching production. I could have all of A, B, C, D, E and F test suites working individually if they break when put together they are all bad. The developer have tests so they know exactly how to reproduce the bug. Time for them to earn their salary.

yabadabadoes 7y ago

I see this over and over also in organizations I work in and even have to fight it in my own behavior.. If you run an end to end test automation and it fails and then you are afraid or otherwise hesitant of doing the process manually you are out of touch with the system and probably missing the forest for the trees when you work on subsystems. While I would like to have better end-to-end tests, I know that I will have to fight more problems of getting too far away from how the system works.

andrewflnr 7y ago

> Well, what's the culprit? A? B? C? D? E? F? Probably, the one you just changed. How often is it really going to be that hard to debug?

thfuran 7y ago
I only changed L, which is nominally unrelated to all of those. You thought this was a clean, well-modularized codebase?
- JohnBooty 7y ago
  You thought this was a clean, well-modularized codebase? Well, even if it's nice and clean A, B, C, D, E are each going to have their own dependencies!
JohnBooty 7y ago
If you change B and the A/B/C/D/E integration test breaks.... duh, it's obvious. Yes, that's easy. But A, B, C, D, E are each going to have their own dependencies. You could change X, Y, and Z and now the A/B/C/D/E integration test breaks. Which one was it? Or maybe you're super cautious and you only change Z. And now the A/B/C/D/E integration test breaks. Obviously it's Z. But how? Why? It's a four-developer team and you're only really familiar with R, S, T, U, V, W, X, Y, and Z. There's also the fact that unit tests serve as living, de facto documentation on how to actually use the classes. You can both use and iterate upon Z a lot faster and more confidently if it has its own tests.
foobiekr 7y ago
The overuse of overly granular services can make this pretty awful unless you've put event tracing in place. I mean, the obvious answer is don't do that, but this is the world people are embracing.