Am I little naive in wondering how this isn't caught in unit, integration and E2E tests?
Edit: looks more involved than that, but it forced me to dig into how some of the components are tested. Educational.
The main Lemmy developers very often don't have the biggest clue of what they're doing, and they've proven that time and time again. A lot of times they forget normal web practices and rules, and a lot of side things like Jerboa are also just broken.
They also don't know how to interact with the community or how to be normal people. Let's not forget they have been working on Lemmy full-time and this is the state we've come to, ignoring all the database and security and everything else issues they already had.
Dude, lemmy is awesome, give them a break.
Lemmy IS awesome, that doesn't mean we can't want it to be better or criticize it. No one said Lemmy isn't great.
The main Lemmy developers very often don't have the biggest clue of what they're doing
this doesn't sound constructive criticism to me.
that commenter has something personal against the devs. Lemmy is far from perfect but it's functional and improving everyday.
Absolutely, but there are constructive ways to do it and what that guy did.
😂😂 I got downvoted for that. I guess people dislike writing tests.
I love writing tests, It's all the shit that comes after that that sucks.
Those first few pushes that all come up green feel like magic. That first red that points out something you missed, you go back and make a quick change and it's now green and it's the best thing you've ever seen.
It's sooner or later, you throw a couple big red bois on a production build that don't make any sense. You start digging through the code of some guy that only writes comments in haiku and has the impression he gets paid by the number of layers deep he can nest a ternary.
Sooner or later you figure out it's just an edge case there's nothing actually wrong. You'll need to refactor one of the systems but you still have production to push to fix a critical bug, so you hotwire the test and write it off as P1 tech debt.
Eventually, you end up with unit tests that aren't P1 and they fail. If you're understaffed, or overscoped, sooner or later you just have a bunch of half-assed zombie test sitting around. Unless you can convince production to let you go back and clear up your tech debt it's just a unit test graveyard. It still has the big bumpers in place so something serious can't fail. But you never seem to be able to get back to make everything bright new and shiny again.
That does sound like a nightmare. I'm assuming you mean failed test when you say "red boy", and that made me wonder about PR practices. I'm used to a very strict review environment and fairly quick review turnaround or requests to go over the code. I've heard horror stories about people not getting PRs reviewed for days or weeks or some people just plain refusing to review code. I work on microservices that are all usually less than 10,000 lines though, not something with over a million lines of legacy code.
I wish more developers would do QA. After working with QA my code improved so much because I was proactively thinking about how things might break or potential issues that I never would have thought of.
Yep. When I was still doing QA, I saw some pretty terrible practices and tested code that barely built. Now as a software engineer, I have no QA and rely heavily on my own testing practices, namely, unit testing first, integration testing and system/e2e testing. I can't guarantee the code is bug free and there's parts I know that could be refactored (tech debt), but I know each piece is tested and does what I expect it to. As corny as it sounds, I'm a big fan of TDD. Unit/IT/E2E don't replace QA in my opinion, but better set QA up to focus on the bugs that matter and not basic stuff.
Am I little naive in wondering how this isn't caught in unit, integration and E2E tests?
Edit: looks more involved than that, but it forced me to dig into how some of the components are tested. Educational.
The main Lemmy developers very often don't have the biggest clue of what they're doing, and they've proven that time and time again. A lot of times they forget normal web practices and rules, and a lot of side things like Jerboa are also just broken.
They also don't know how to interact with the community or how to be normal people. Let's not forget they have been working on Lemmy full-time and this is the state we've come to, ignoring all the database and security and everything else issues they already had.
Dude, lemmy is awesome, give them a break.
Lemmy IS awesome, that doesn't mean we can't want it to be better or criticize it. No one said Lemmy isn't great.
this doesn't sound constructive criticism to me.
that commenter has something personal against the devs. Lemmy is far from perfect but it's functional and improving everyday.
Absolutely, but there are constructive ways to do it and what that guy did.
😂😂 I got downvoted for that. I guess people dislike writing tests.
I love writing tests, It's all the shit that comes after that that sucks.
Those first few pushes that all come up green feel like magic. That first red that points out something you missed, you go back and make a quick change and it's now green and it's the best thing you've ever seen.
It's sooner or later, you throw a couple big red bois on a production build that don't make any sense. You start digging through the code of some guy that only writes comments in haiku and has the impression he gets paid by the number of layers deep he can nest a ternary.
Sooner or later you figure out it's just an edge case there's nothing actually wrong. You'll need to refactor one of the systems but you still have production to push to fix a critical bug, so you hotwire the test and write it off as P1 tech debt.
Eventually, you end up with unit tests that aren't P1 and they fail. If you're understaffed, or overscoped, sooner or later you just have a bunch of half-assed zombie test sitting around. Unless you can convince production to let you go back and clear up your tech debt it's just a unit test graveyard. It still has the big bumpers in place so something serious can't fail. But you never seem to be able to get back to make everything bright new and shiny again.
That does sound like a nightmare. I'm assuming you mean failed test when you say "red boy", and that made me wonder about PR practices. I'm used to a very strict review environment and fairly quick review turnaround or requests to go over the code. I've heard horror stories about people not getting PRs reviewed for days or weeks or some people just plain refusing to review code. I work on microservices that are all usually less than 10,000 lines though, not something with over a million lines of legacy code.
I wish more developers would do QA. After working with QA my code improved so much because I was proactively thinking about how things might break or potential issues that I never would have thought of.
Yep. When I was still doing QA, I saw some pretty terrible practices and tested code that barely built. Now as a software engineer, I have no QA and rely heavily on my own testing practices, namely, unit testing first, integration testing and system/e2e testing. I can't guarantee the code is bug free and there's parts I know that could be refactored (tech debt), but I know each piece is tested and does what I expect it to. As corny as it sounds, I'm a big fan of TDD. Unit/IT/E2E don't replace QA in my opinion, but better set QA up to focus on the bugs that matter and not basic stuff.