Agree with mocks also, currently not even using them, just go with integration tests and set db back to known state between every test run, oh and wiremock for rest
https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...
Rule of three ("Three strikes and you refactor") is a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code do not require refactoring, but when similar code is used three times, it should be extracted into a new procedure.
If your “DRY” change PR removes 1 repeated piece of code but adds in 1 kind of nonsensical abstraction, 1 extra coupling between two pretty unrelated things that use that abstraction, 1 change to the input and output of the function, 1 test suite testing for two separate “things”, etc. it’s not sounding like such a clear positive contribution to the codebase.
If we want to go by some of the old adages then a non-dogmatic reading of Single Responsibility - the abstraction should be about one thing - is pretty good in my book.
Or I'm just dumb.
There's little to no point in doing mocks if your logic is not really complicated where you would need to separate testing it from the integration test.
I think a lot of people took "TDD" a bit too much to the heart and it ended up maligned where always more tests == better.
I know the book said so, but can we please just talk about the reality of our situation.