this post was submitted on 12 Sep 2023
825 points (99.0% liked)

Programmer Humor

19471 readers
30 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] alphacyberranger@lemmy.world 22 points 1 year ago (5 children)

Everyone talks about testing, but I have never seen it in the wild

[–] Jaydeep@lemmy.world 12 points 1 year ago (1 children)

It's common in critical projects.

[–] alphacyberranger@lemmy.world 11 points 1 year ago* (last edited 1 year ago)

Chuckles.... you have not worked in my company.

[–] fibojoly@sh.itjust.works 8 points 1 year ago

After many years (10+), I finally find a company that actually, really, implements CI/CD. Then I look at the tests and it's actually the most inane shit imaginable, tacked on top of ancient existing code, not maintained. I spent more time fixing the stupid tests than actually fixing the bugs I was tasked fixing. Amazing.

[–] gerryflap@feddit.nl 5 points 1 year ago

I can't really imagine working on any code base that has to actually be maintained and doesn't have tests. The amount of times that tests have safed my ass at my job are uncountable

[–] buzziebee@lemmy.world 5 points 1 year ago (1 children)

We test the shit out of our Apis. We do more API level/integration testing though.

I.e. a test will be something like "if the db is in this state, and we hit this endpoint with these params, does it return what we expect and update the db correctly".

Our app is primarily about users maintaining stuff on big datasets with complicated aggregation and approval logic. So setting up a scenario and checking the app does what the business logic says it will do is what we want to know.

It makes refactoring wayyyyy less painful to just know that the app will always behave itself. Rather than testing whether a function can add 1 + 2 correctly, we can test each endpoint does what it's supposed to do.

It gives us loads of confidence that the backend is doing what it's supposed to. If you do a huge refactor you don't need to worry about whether you broke the test or if the test is failing correctly. If the tests all pass everything is working as it should.

Downside is longer test execution times (because a temporary db needs set up) when running the full suite. Worth the trade off for us though.

[–] jaybone@lemmy.world 1 points 1 year ago

Those are good tests. But that sounds more like an integration test than a unit test. And we should have both.

[–] huginn@feddit.it 2 points 1 year ago (1 children)

Meanwhile I'm very upset our unit test coverage is only 40%.

Like, it's the number 1 priority for the principle & staff engineers to get that up to 80% across the codebase.

[–] floofloof@lemmy.ca 2 points 1 year ago

And it's number 1 priority for management to employ as few developers as possible and stretch their team as thinly as possible. Hence still no unit tests in any of the companies I've worked at recently, despite everyone knowing they're worth it, including lip service from management. They just won't invest in testing, no matter what. One company even fired all the testers then complained to the developers that the product was getting less reliable.