Live data from Hacker News

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

amazingcto.com

1–10 of 81 posts

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

#2
I found that a suite of useful tests speed up my development by a lot.

Tests that test services that do interesting thing in my code. I find that I can get 90% of my work done without ever firing up a web browser. It's cool to know that by the time you hit up the ui the code already works perfectly and I spent less time coding than otherwise.

So idk what this article is pointing out. Tests for test sake is probably that, but a big chunk of unit testing is definitely not bad for developers.

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

#3
> When found during development, developers need to write a fix; the time spent counts against “development time.” They are blamed for missed deadlines (Newspeak “Sprint and Goals”). They are asked why everything takes so long. Ironically, they are blamed for creating high-quality code. Sad, I know.

Hahaha, I have been penalized for going steady enough times that I reached a point where I have no incentive to make services any better. I found it better to sweep issues under the rug and switch teams before it blows up.

It pains me but I am not going to care about it if I am going to be penalized for it.

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

#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 proactive you might grab session data but that means potentially sensitive user data is being cached and passed around to the support/triage team. At a security minded organization this should be impossible or at least difficult.

I agree it's not worth chasing Test Driven Development until you're actually testing during development.

This is a real problem, and it falls squarely on management. Testing needs time and resources, it needs priority and planning.

That's the reason I started speaking at conferences, started an online testing training course specifically for software managers, and am currently writing a book on the subject.

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

#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.

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

#7
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.

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

#8

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.

Man have I been on either side of those

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

#10
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 disagree. Unit tests, when done right, are heaps of ROI in my experience.

Most of the integration tests are for happy paths, i.e. ones where you can catch the obvious regressions. Testing corner cases is much more troublesome, because you have to set up a whole lot of specifics in multiple services. These are much easier to simulate with mocks.

Mind you, I hate unit tests for specific functions: I much prefer them as component tests, where you start with the inputs to the module and check the outputs and calls outside of the module. These ease refactoring where you actually change the underlying code and without changing the unit tests, you know that you also handled all those pesky corner cases.

Post reply on HN