Live data from Hacker News

For developers under pressure, it’s better for bugs to be found in production

amazingcto.com

11–20 of 81 posts

Re: For developers under pressure, it’s better for bugs to be found in production

#11
> So if tests are bad for developers, they won’t write tests, duh. Paradox solved. There need to be tests written, no exceptions, for some time to gain the benefits and make tests good for developers. Make tests work for them and they will write more.

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.

Re: For developers under pressure, it’s better for bugs to be found in production

#13
post #5

Maybe 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…

> potentially sensitive user data is being cached and passed around to the support/triage team

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

#14
post #6
post #4

I'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.

Unit tests (which have to mock dependencies) have a very bad signal-to-noise ratio. Most of their breakages are caused by forgetting to reflect the latest implementation details in the test code (like mocking new dependencies).

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

#15
post #4

I'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

They are valuable in different ways.

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

#16
post #4

I'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

Horses for courses. In an environment where a compiler has nodded approvingly to tight type constraints that limit mistakes to a rather high level, I'm very much in the same boat. Bugs that get through those checks are often wrong assumptions about the environment outside of the unit, and chances are those wrong assumptions would also go into the unit test. If that happened, the test gives nothing but false confidence, which makes its value a net negative even before you start considering the effort that went into writing.

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

#17
post #4

I'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

"Does our code work?" is a different question than, "is the service working?"

Re: For developers under pressure, it’s better for bugs to be found in production

#18
post #4

I'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

I think people disagree and argue about this so much because each preference is true in that developer's context and environment. Everyone who voices a general opinion should indicate what kind of development they do.

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

#19
The central hypothesis is that developers are not writing tests since they prefer bugs popping up on production instead of during development, and it seems quite absurd. I've been in many dev teams in many companies, but haven't seen incentives to be that much messed up.

One 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

#20

Developer'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.

Can I still not write tests because I don't know how or because I simply don't want to and put the "fucked up" pin on someone else ?
Post reply on HN