3 ms·
> I've found that unless I write code in golang in a way that was intentionally written to be unit tested, it is very hard to bolt on unit testing after the fac
by randomdata 4y ago
> I've found that unless I write code in golang in a way that was intentionally written to be unit tested, it is very hard to bolt on unit testing after the fact.
Absolutely. This is true in most, if not all, languages. But when you're in the driver's seat, able to make choices like whether or not to use fx, why would you bolt on testing after the fact?
Not much you can do about legacy code, if that's what you have to deal with, but when dealing with legacy code it is unlikely the authors used fx, so...
- latchkey 4y agoAs you refactor the code to be more testable, you can add in fx. It doesn't have to be from the beginning.
- randomdata 4y agoIf you refactor code to be more testable then it is testing that is forcing you, not fx.
- latchkey 4y agoCorrect, I haven't argued any differently. You introduce fx in, start writing tests and it will convince the other developers you're working with that there is importance to how you build the codebase in such a way as to enable testing.
- randomdata 4y agoThen you must have mistakenly replied to the wrong thread? If you are in a position where you can introduce fx, then you are also in a position to introduce testing, and testing will already force testable code. If fx can help your code, great, but that's orthogonal to the discussion.