My personal pet-peeve is when the obsession with DRY carries over to testing. Testing is not the place for DRY. Reading a test should be like reading a recipe: do A then do B, then do C, then expect result X. When you start abstracting the setup to the nth degree it becomes much harder to understand the test because you have to click around the code to following the abstractions like a trail of bread crumbs, when really what you want is for the stack trace to say "error on line 123" and the cause to easily found near line 123. Tests shouldn't be dry, they should be wet.
It's a trade off for sure. I have seen people write test code with no regards to DRY and it results in tests that are hundreds of lines of setup trying to wire up the inputs and the expectations when a little bit of thought to remove all that repetitive code would go a long way in making the tests readable.
I do agree that there doesn't need to be obsession with DRY when it comes to writing tests (esp when you are bouncing around multiple functions and files just to understand the testcase) but completely abandoning it either isn't great either.
Usually hunderds of lines of set up code point out the issue in the code itself -it's usually a smell of a god object/function that has too many responsibilities
I've run into exactly this, where each developer has their own test setup abstraction and attempt at automation. Difficult to add your own tests and difficult to fix theirs. It's maddening.
