Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "i hate unit tests"
-
I hate, HATE MYSELF!! I am an awful developer. I am an awful person.
I am trying so hard. To be a better person. To be a better developer. But, as a person I am again finding it difficult to empathize. At work, I really want to explore MERN stack but that I have to do it out of working hours. And damn! work is too much, I don't get time.
I need to work on a new project, for 2 months the discussions with MILLION TEAMS ARE GOING ON!!! NOTHING!! NOBODY HAS ANY IDEA!! THEY MIGHT FIRE ME!! I AM STRESSED!!
IT'S 1AM HERE AND I AM WRITING UNIT TESTS!! I want to cry. I want a partner maybe who can support me or maybe it's my mood swings.29 -
It works.
How I hate that sentence.
Whenever that sentence pops up, I wanna take a frying pan, make some bacon, eat the bacon and slam the still hot pan with grease through someone's face till the skull breaks.
Why has he so many anger issues, one might ask.
Usually the sentence "It works" means that after looking at "working thing" it works wrong in 95 % of all cases, but hey - for 5 % it at least does *something* right. Not everything, don't get ya hope up.
We had this fun topic happening again today and I'm still too angry to sleep.
Lucene analysis of texts in Elasticsearch.
Stopword list? Multiple word n-grams per line, duplicates, not lower cased, not properly encoded.
Tokenizers? Duh. Why should one put them in proper order.... Or more realistic: There is an order in tokenizers necessary *devs with shocked faces*.
Language specific details... UHM. Wait. Languages are different? There are edge cases in languages? *more shocked faces*.
Even more shocking that if an text processing pipeline is implemented horribly wrong, it delivers wrong results. *mind blown*.
But our unit tests (this goes out to @kiki) were working.
Yeah. You dumb nuggets who even an amoeba would be ashamed of, when you only do positive tests in unit tests with the most obvious working examples, then your unit tests are just useless waste of nibbles.
Some of the devs are really a fucking waste of genetic information, should have probably ended better in a sock.
If this sounds too harsh, they had 2 weeks.
In just 3 hours I found out that they can redo that with supervision.
-.-
I'm getting too old for that shit. Seriously.4 -
I fucking hate the fact that this group I'm side-hustling for gives maintainer access to every shitty dev they have.
Dev pushes four commits directly to master branch. Each time, pipeline fails on unit tests.
Shithead ignores failed tests and manually deploys to stage anyway.
Fuckface then declares (in group chat) that her "fix" works on stage and proceeds to merge to RC branch without updating the fucking unit test.
Pipeline fails (of course) and remains unfixed for the last EIGHT FUCKING HOURS.
This is what I woke up to at 6-fucking-AM in the god-damn morning.
*insert multiple expletives and insinuation of mother's excessive girth by comparing waistline to equator1 -
When I was a junior engineer I used to hate writing unit tests but now I look forward to writing them.
Well written Unit tests will save your life6 -
Fixing unit-tests that expects 2017... kills my motivation at first workday this year.... I hate my coworker -..-
-
I HATE the idea of only releasing on pre-determined schedules despite work being completed and just waiting for that day to arrive.
I'm a co-founder of a small software company. We have partnered with another particular company that also writes software. Some of our clients have access to paid content of that company's services through our application.
Every once in a while, our clients will report issues with that company's service to us, because they access it through our application. They think it's our issue.
We then pass the report on to the partner company, telling them that their stuff is broken. Their reply goes like this:
"Ok. We'll get the bug fix scheduled, and we'll release it next Thursday."
"Next Thursday? The issue is now, they can't use the service."
"That's our scheduled release date."
O.M.G.
We voluntarily walked away from our safe, cushy jobs working for other people, taking enormous pay cuts to start this company. Now, we're 6+ years in, disrupting established fat-and-happy competitors in this space. I GUARANTEE you that if we had that same attitude, we would have been absolutely obliterated early on.
We are quick. Guided by kanban boards, our suite of unit tests and integration tests is vast and kick-ass. With continuous integration and the click of a button we know if we broke something or if the piece we're working on is ready to be pushed to production, IMMEDIATELY. Our "release schedule" is when the damn thing is complete.
It isn't all bad. Our integration with them has been beneficial for both of us. I just loathe their snail's pace which negatively affects our mutual customers. It can make us look bad, and we can do nothing about it.
Blah.3 -
JS/NODE/MOCHA I HATE U....
SPENT ALL MORNING REVERTING AND DEBUGGING A BRANCH BC SOME UNIT TESTS FAILED.
THE CAUSE WAS NOT IN THE FAILED CASE THO.... IT WAS BECAUSE SOME OTHER JS FILE WAS NAMED *Test.js
ITS NOT A PROBLEM IN A LIVE SERVER BUT IT SCREWS UP THE SERVER WHEN ITS RUN IN MOCHA FOR ITS UNIT TESTING... -
Who I hate:
People who put their tasks to ready for (integration) test without even once running it against real services and the actual database instead just the mocks of the unit tests.
=> I want to test business logic, not fix your internal server errors... -
I hate deploying this project, it's just nerve wracking. I started it when I was a newbie to web stuff so I didn't know shit. Now it's just a big project with no unit tests, I test it all by hand.
It looks professional though, but the underlying code is just a mess.5 -
I hate unit test. I hate testing by code.
I hate the idea to write code that tests code. And that u must update both when u add a feature. Like wtf.
Good debug mode with clear verbose and precise reporting tool and voila.
Drives me nuts thus trending shit.10 -
I really hate how steep the learning curve is for testing. I've been writing the same test for a week for a 150 line directive, and it's driving me fucking nuts. Nothing makes sense. No one in the office to help me. Only 10% of engineers here write any tests. I don't know what to do. Overnight they made it a rule that if you want to move up to the next level for software engineers, 80% of your code needs to have unit test coverage. It's just bullshit.3
-
I hate meteor. I hate that I have to have everything I do revolve around meteor and it's packages. I hate that I cant implement HMR without support from meteor or tearing my hair out for hours on end. I hate the special implementation of unit tests that have to accommodate for the fact that meteor sucks so much. I hate the encapsulated bubble of "meteor" packages that install themselves outside of my development directory. I hate that I can't use most of the code I find while researching problems because it doesn't work inside of the meteor bubble.
I did not start this project. I did not select meteor as a starting point because I didn't want to implement my own full stack solution, of which there are many that are far better in almost every way, and watch everyone else that touched my code suffer from day one.
If it is the last thing I do, I WILL purge meteor and all of it's nonsense from every line of code in this application even if that means rewriting every line of code in this application.
I will have no mercy. There will be screams of agony, gnashing of teeth and blood will flow down the streets like the rivers of hate that flow in my heart for meteor and all things it stands for.
I will have my vengeance, and it will be terrible.1 -
Airflow… airflow… I hate you so freaking much, you are a bloated piece of software that packages wayyy too much and increase the complexity of any solution we built on top of you. Plus unit-testing and integration tests are wayyy too difficult with you. But man… your recent UI changes are a massive welcome.
A year ago I was tasked with either upgrading airflow to version 2 or to migrate the code to another tool. Naively I thought “well might as well upgrade to avoid a rewrite”. Little did I know that the reason airflow didn’t scale out well for us, was due to people over the years not having a grasp on airflow primitives like “pools”, “workers” and “operators”. Ended up refactoring the entire codebase for both infra and DAGs anyhow AND upgrading the beast AND lower cost by a factor of 2 (from $100-$150 daily to $50-$70 daily).
But seriously feels like I could’ve solved the scheduling issue with literally any message queue+decent library (like celery or Faust) and I’d have half the headache.3 -
#Suphle Rant 3: Road to PHP8, Flow travails
Some primer: Flows is a feature that causes the framework to bypass handling the request now but read it from cache. This cache entry is meant to be populated without warming, based on the preceding request. It's sort of like prefetching but done on the back end
While building Suphle, I made some notes on some chapters about caveats and gotchas I may forget while documenting. One such note was that when users make the Flow request, the framework will attempt to determine who user is, using authentication mechanism defined on the first module (of the modular monolith)
Now, I got to this point during documentation and started wondering whether it's impossible for the originating request to have used a different authentication mechanism, which would result in an empty entry for returning user. I *think* it's possible cuz I've got something else called "route mirroring", where web based routes can be converted to API routes. They'll then return JSON, get served under defined API path, use JWT, all automatically. But I just couldn't connect the dots for the life of me, regarding how any of this could impact authentication on the Flow request
While trying to figure out how to write the test for this or whether it was even necessary (since I had no use case), it struck me that since Flow requests are not triggered by an actual user, any code attempting to read authenticated user will see nothing!
I HATE it when I realize there's ambiguity or an oversight, after the amount of attention and suffering devoted. This, along with a chain of personal troubles set off despondency for a couple of days. No appetite for food or talk. Grudgingly refactored in this update over some days. Wrote some tests, not all passed. More pain. May have to convert them to unit tests
For clarity, my expectation is, I built this. Nothing should be impossible for me
Surprisingly, I caught a somewhat lucky break –an ex colleague referred me to the 1st gig I'm getting in 1+ year. It's about writing a plugin for some obscure forum software. I'm not too excited cuz it's poorly documented and I'll have to do a lot of groping, they use arrays instead of objects etc. There's no guarantee I'll find how to implement all client's requirements
While brooding last night, surfing the PHP subreddit, stumbled on a post about using Rector to downgrade a codebase. I've always been interested in the reverse but didn't have any incentive to fret over it. Randomly googled and saw a post promising a codebase can be upgraded with 3 commands in 5 minutes to PHP 8. Piqued my interest around 12:something AM. Stayed up all night upgrading it, replacing PHPSTAN with Psalm, initializing the guy's project, merging Flow auth with master etc. I think it may have taken 5 minutes without the challenge of getting local dev environment to PHP 8
My mood is much lighter than it was, although the battle is not won yet –image tests are failing. For some weird reason, PHP8 can't read generated test images. Hope I can ride on that newfound lease on life to study the forum and get the features working
I have some other rant but this is already a lot to digest in one sitting. See you in rant #4 -
As an android dev when I inherited a shitty project thats when I realized what really means to write readable and most importantly testable code. Codebase I inherited wasnt even really that bad it was quite readable, but boy it was not suited for any unit/instrumented tests. im talking spaghetti code.
Nowadays I refactor apps to make sure they are testable instead of spending weeks writing tests for a shitty codebase which was done without thinking about separation of concerns. Clients hate the extra couple weeks on top of request but what can I do, if they want tests they need to work with TDD approach or give extra time for refactors.