I have found “Don’t repeat yourself” to cause the biggest mess many times. I’m guilty of this myself and I’ve inherited some really deeply nested inheritance chains where people thought it was best with 4-5 levels deep inheritance rather than just duplicating a couple of methods in a select few classes.
Especially in ruby where interfaces are missing it becomes really hard to refactor this code. Even worse then when one of those methods that all children uses have if or case statements with the type of child to skip or explicitly run some other method. BOOM not doing that again.
I like duplication, if it really is something that can be purely used without checking who it is that is running the code I might extract it but that is not my first choice.
Oh and also, I don’t write that many unit tests. I prefer business or use case driven tests/design/architecture. I’ve found especially stubbing to be a pain in the neck. Many times people just throw in a double and make it run some code. I can’t even count how many times the stubbed code doesn’t even match the underlying implementation... Nah, use real world code, test real implementation. If performance really becomes an issue then by all means I’ll consider refactoring the tests.
One of the gems I am maintaining has more than 500 (mostly) integration tests. Connects to redis,
stores a bunch of data etc. Test Suite finishes in around 5 seconds even though I have some sleeps and the likes due to implementation being asynchronous.
I went from untrustworthy unit tests that caused problems in production to reliable test suite that I can trust. Don’t stub business logic unless you really have to is my go to.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.