4 ms·
Very much agree with "sprinkle TDD around for a high ROI" This requires both developer expertise and trust from stakeholders. But, VeryBigHugeBankCo requires m
by mring33621 5y ago
Very much agree with "sprinkle TDD around for a high ROI"
This requires both developer expertise and trust from stakeholders.
But, VeryBigHugeBankCo requires me to have 70% unit-test coverage for 'new' code, as measured by Sonar or whatever, or else I am simply not able to deploy my change to PROD.
So here I am refactoring a DAO, using strategy pattern and functional interfaces, so that I can cover my DB interactions adequately for that 70% metric.
No, I can't just use H2 DB, as the SQL is Oracle-specific.
Yes, there is very little actual value in the new refactor, except to check the box.
This is how we do...
- mring33621 5y agoOh and don't get me started about how, especially when using mocking frameworks, the test code is sometimes wayyyy harder to understand than the actual code under test. NOT A WIN. I have told mgmt that test code is equally likely to have bugs as production code, but, again, this is just box-checking, not actual attention to detail.
- thow-58d4e8b 5y agoIt gets worse than that. Often, code is pushed into an absurdly wrong level of the development stack, just because it makes testing it easier. For example, something should be a database trigger, but in-memory testing database gets in the way. Other times it strikes all the way to architectural topics - message queues replaced by REST calls, because the former is difficult to mock
- mring33621 5y agoYup. I open a 'test-mode-only' socket on our ingestion piece, for integration testing, as I can't easily get onto our MQ (even non-prod).
- nicoburns 5y ago> in-memory testing database gets in the way Why would using an in-memory database prevent use of triggers?
- oxff 5y agoThis seems particularly bad scenario to be in, as being forced to write more lines of code increases any attack / bug surface (?)