4 ms·
Unit testing is a tool, you don't need a 100% test coverage. But sometimes it's the right tool for the job. Sometimes it's not. If I have a piece of code...
by swalsh 5y ago
Unit testing is a tool, you don't need a 100% test coverage. But sometimes it's the right tool for the job. Sometimes it's not. If I have a piece of code... usually an algorithm that handles a handful of different use cases, and making a change might unexpectedly cause an issue to another use case, i'll unit test the heck out of it. If I have some code where it has a simple input, and output but it takes some time to test it, i'll write a unit test to make development faster.
But i'm not going to add an interface to every concrete class in my project, and design literally every component so I can mock it.
Writing software is a business, i can sprinkle TDD around for a high ROI. If I use it EVERYWHERE the ROI is very little if not negative.
- mring33621 5y agoVery 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 (?)