You guys have unit tests…?
Ohh yeah, loads! Do they actually test anything useful? Not so much.
I actually had to refactor configuration module some time ago. These really came in handy. But was it worth it? Well… it saved some time, the time that could be used to debug problems manually, but it made me a lot more confident that the functionality that worked before, worked after.
You just have to mock everything, so it’s basically testing nothing. But you get those code coverage numbers.
deleted by creator
The ones I have seen so far are probably written by the same people who don’t understand the usefulness of comments, I reckon. And maintained with the same enthusiasm.
The one I hate? Your unit tests pass when run locally, and in your sandbox environment, and in dev, and in UAT, but prod? Fuck that, failing with reckless abandon.
Unit tests or integration tests?
Yes
Are you kidding me? Tests in prod? Hopefully that means you didn’t fully roll out. That means someone didn’t get a 3am page.
This sounds like a god-damned resounding success.
Everyone talks about testing, but I have never seen it in the wild
It’s common in critical projects.
Chuckles… you have not worked in my company.
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.
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.
Those are good tests. But that sounds more like an integration test than a unit test. And we should have both.
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
Ahhh my favorite way to fix a broken test: just remove it!
Mark it as intended-to-fail, that way if someone fixes your bug it’s their test failure.
I’m in this meme right now.
I just made a tiny change that somehow broke a major feature in testing. The disbelief is real.
Rollback, tests still fail.
Flip a table.
sometimes it is the unit tests.
Oof I am here right now, which is why I’m procrastinating on socials…
