Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

amazingcto.com

Post reply on HN
Print view View original

21–30 of 81 posts

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

#21

Post by yadaeno »

gdsdfe wrote: 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

If your class needs lots of mocks to be tested it may be a sign that there is too much abstraction/complexity.

You should prefer to instantiate your class with real objects, if you can’t do that then use fakes, as a very last resort you can use a mock but at that point your test is probably useless.

(The exception) If you have an class that is a wrapper around some HTTP requests, then it is fine to mock these HTTP calls. If you have a test that depends on this class, then you can use either mock these calls again, or upgrade to a fake if the mocking is too complex.

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

#22

Post by ajmurmann »

jackblemming wrote: post #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.

This is were good tech leadership matters. Leadership must push back on product to make room too build out test infrastructure. Otherwise you'll see individual engineers who do the right thing get punished for it because get aren't delivering tickets.

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

#23

Post by CSMastermind »

The_Colonel wrote: post #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 the…

I mean I've seen it happen with unrealistic stakeholders. Business forces the team to make a false commitment to a specific ship date with a specific set of features. It's obvious that the team can't hit that mark but telling the stakeholders that will just result in them refusing to budge and telling you that you need to come up with a plan to make it happen.

Eventually it's easier to just agree with them and do your best than waste even more time arguing with them. Eventually you fail to ship or you ship a buggy mess. The software engineers know the code quality is shit but they don't have time to think or set anything up.

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

#24

Post by rozenmd »

kapitanjakc wrote: post #20
jackblemming wrote: post #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.

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 ?

> I don't know how

See the first point

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

#25

Post by orwin »

jackblemming wrote: post #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.

Writing tests, if you have to mock everything each time because you can't duplicate the production, isn't really hard. It's long and boring.

If I have to ballpark an estimate on a tool/project, I say upfront something like: it'll take me 6 days olus a day for very limited tests, so 7. Twice as much with almost complete coverage. But each time we'll have to improve/refractor, a bit of that time will be recovered.

Basically I ask how important the new project will be,without asking that (because 99% of the time the response is 'very').

I'm realizing I just say I was managing my managers. Should I ask for senior devops position now? :)

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

#26

Post by SpicyLemonZest »

The_Colonel wrote: post #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 the…

The QA model you're describing isn't universal. In most of my roles there hasn't been any sort of separate QA team that stands between the dev team's code and production. So if you have a small enough set of customers that you can be confident they won't hit certain categories of bugs, or won't care too much if they do... it's tempting, and I've seen it done on occasion.

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

#27

Post by kapitanjakc »

The real reason I don't write the tests:-

Client/ Manager :- When is this going to be ready?

Me :- Estimated time for development is n1 days and around n2 days for testing, and depending on the bugs n3 days to fix them.

Client/manager :- No no, we don't have time, do it in n1-1 days.

And when you ship it with bugs, they have a shocked Pikachu face.

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

#28

Post by umvi »

gdsdfe wrote: 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

Unit tests are valuable for certain types of code, mainly library code in my experience. For example if you are developing a 3d math library, unit tests will be invaluable.

Unit tests are less valuable for testing applications because the unit tests end up just being mirrors of your application classes/functions and you have to make changes in 2 places now any time you need to tweak application logic.

For applications I think black box tests have the highest ROI. Your application should have a headless mode through which you can send all of your test cases (real life inputs) and verify the output of your app has expected shape/value. As you encounter issues from user feedback, simply add to your list of black box tests. The beauty is that down the road you can "rewrite your app in Rust" or whatever and you'll have a huge set of black box regression tests you can use to validate the rewrite.

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

#29

Post by kapitanjakc »

rozenmd wrote: post #24
kapitanjakc wrote: post #20

Earlier quoted context omitted.

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 ?

> I don't know how See the first point

Hell yeah.

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

#30

Post by Dudester230602 »

jackblemming wrote: post #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.

There are two kinds of developers:

A - puts a brand new project on CV and moves on before go-live.

B - stays behind to handle going-live issues and maintain.

Guess which kind sees pay growth and promotions?

Post reply on HN