This doesn't actually fix the incentive problem, though. If the reason developers don't like writing tests is because finding bugs puts them under additional pressure and isn't rewarded, requiring this so doesn't actually help them. Unless, of course, management comes to understand and accept that more time will be spent fixing bugs/improving code quality as a result.
For developers under pressure, it’s better for bugs to be found in production
11–20 of 81 posts
Re: For developers under pressure, it’s better for bugs to be found in production
#12Re: For developers under pressure, it’s better for bugs to be found in production
#13Maybe not perfectly framed, but the point that engineers don't have time to write tests is salient. Minor disagreement with this point though: > Tests can only tell developers they made a mistake. There is no gain at that moment. The value is locating the problem code faster, and that generally can't be done efficiently in production. Outside a testing environment, you rely on logs alone to debug, or if you're more p…
An excellent point for most cases that ultimately cannot be satisfied for others. For instance, this most recent HTTP/2 Rapid Reset vulnerability, could it be solved without shared PCAPs?
Re: For developers under pressure, it’s better for bugs to be found in production
#14I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks
Doing both is good. Integration tests tells you that something is broken. Unit tests tells you where it broke.
I write unit tests only if the logic is completely encapsulated by the "unit". The less you need to mock, the higher value the tests bring. That's one of the reasons I prefer to work on monoliths, it's much easier to test almost-end-to-end.
Re: For developers under pressure, it’s better for bugs to be found in production
#15I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks
Integration tests are better at accurately reflecting the real software. There is less of a leap of faith between "this test passes" and "the software actually works".
Unit tests are better at telling you exactly what failed. There is less of a research project between "this test fails" and "this code right here needs to be fixed".
I don't really love anxiety-inducing leaps of faith or time-consuming research projects, but I don't know of one form of testing that avoids both.
Re: For developers under pressure, it’s better for bugs to be found in production
#16I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks
But at the other end of the spectrum (say, php), things are very different. You want that code exercised, just to be confident that it will actually do something, anything. Even if the question wether those things it does are right or wrong is left to higher level tests.
Re: For developers under pressure, it’s better for bugs to be found in production
#17I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks
Re: For developers under pressure, it’s better for bugs to be found in production
#18I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks
How could it possibly be that unit tests are "good" or "bad" in general, for all software development?
Re: For developers under pressure, it’s better for bugs to be found in production
#19One reason this doesn't make much sense is that this requires hoping that the bugs pass QA. If QA finds those bugs, sends them back to dev, then they still have to fix that + very significant time overhead of this round trip which doesn't make it "worth it".
Re: For developers under pressure, it’s better for bugs to be found in production
#20Developer's dont write tests if writing tests is hard. Simple as that. If writing tests is hard because you never invested in setting up a good test infrastructure with helpful utilities, you fucked up. If writing tests is hard because your architecture is a cluster fuck of mixed responsibilities, you fucked up.