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 - "test coverage"
-
Fuck the memes.
Fuck the framework battles.
Fuck the language battles.
Fuck the titles.
Anybody who has been in this field long enough knows that it doesn't matter if your linus fucking torvalds, there is no human who has lived or ever will live that simultaneously understands, knows, and remembers how to implement, in multiple languages, the following:
- jest mocks for complex React components (partial mocks, full mocks, no mocks at all!)
- token cancellation for asynchronous Tasks in C#
- fullstack CRUD, REST, and websocket communication (throw in gRPC for bonus points)
- database query optimization, seeding, and design
- nginx routing, https redirection
- build automation with full test coverage and environment consideration
- docker container versioning, restoration, and cleanup
- internationalization on both the front AND backends
- secret storage, security audits
- package management, maintenence, and deprecation reviews
- integrating with dozens of APIs
- fucking how to center a div
and that's a _comically_ incomplete list; barely scratches the surface of the full range of what a dev can encounter in a given day of writing software
have many of us probably done one or even all of these at different times? surely.
but does that mean we are supposed to draw that up at a moment's notice some cookie-cutter solution like a fucking robot and spit out an answer on a fax sheet?
recruiters, if you read this site (perhaps only the good ones do anyway so its wasted oxygen), just know that whoever you hire its literally the luck of the draw of how well they perform during the interview. sure, perhaps some perform better, but you can never know how good someone is until they literally start working at your org, so... have fun with that.
Oh and I almost forgot, again for you recruiters, on top of that list which you probably won't ever understand for the entirety of your lives, you can also add writing documentation, backup scripts, and orchestrating / administrating fucking JIRA or actually any somewhat technical dashboard like a CMS or website, because once again, the devs are the only truly competent ones - and i don't even mean in a technical sense, i mean in a HUMAN sense of GETTING SHIT DONE IN GENERAL.
There's literally 2 types of people in the world: those who sit around drawing flow charts and talking on the phone all day, and those WHO LITERALLY FUCKING BUILD THE WORLD
why don't i just run the whole fucking company at this point? you guys are "celebrating" that you made literally $5 dollars from a single customer and i'm just sitting here coding 12 hours a day like all is fine and well
i'm so ANGRY its always the same no matter where i go, non-technical people have just no clue, even when you implore them how long things take, they just nod and smile and say "we'll do it the MVP way". sure, fine, you can do that like 2 or 3 times, but not for 6 fucking months until you have a stack of "MVPs" that come toppling down like the garbage they are.
How do expect to keep the "momentum" of your customers and sales (I hope you can hear the hatred of each of these market words as I type them) if the entire system is glued together with ducktape because YOU wanted to expedite the feature by doing it the EASY way instead of the RIGHT way. god, just forget it, nobody is going to listen anyway, its like the 5th time a row in my life
we NEED tests!
we NEED to know our code coverage!
we NEED to design our system to handle large amounts of traffic!
we NEED detailed logging!
we NEED to start building an exception database!
BILBO BAGGINS! I'm not trying to hurt you! I'm trying to help you!
Don't really know what this rant was, I'm just raging and all over the place at the universe. I'm going to bed.20 -
So today, again, I discovered the importance of unitests.
I was solving this performance issue, in which we had a few update actions for multiple entities in mongo, but it took FOREVER to complete, even when I unified it into one bulkWrite command.
Since the unified write did improve performance slightly, and we wanted to move on, we decided to let this bug go.
So there I was committing my changes when I got a rejection from the pre-commit hook since I didn't have enough unitests coverage.
Ok, let's start writing some unitests.
Some unitests also needed to test the bulk write. So there I was comparing expected with actual result, and suddenly I got a huge facepalm.
Apparently some rogue for loop iterated all entities again for each entity that needed update. So instead of getting one update per entity, I got N identical update commands per each of the N entities 🤦♂️
Needless to say, fixing this fixed the performance bug entirely.
Thank you unitests and pre-commit hooks!2 -
Next year I will strive to achieve the best test coverage on all our components and design all our new features using best-practice agile methodology with a realtime user involvement.
Reverend on 7 January: Fuck that, we need to ship this shit to production now. -
My biggest problem with Visual Studio Code is that every fucking piece of shit dev thinks it's their duty to introduce it to me. STOP. Just stop this shit, alright? Wanna use vscode? Fine, just don't tell me it's the best tool and I MUST use it instead of the tools I'm used to. I'm tired of this bullshit.
Every new project, every new team. Starting from js/java/.net monke and ending with PMs, I must hear this bullshit about god blessed IDE that I must use, because "why you need intellij/webstorm/rider? just install vscode and some plugins. we all use it in our project and it's ok".
FUCK YOU! Refactoring is not just renaming variables and extracting blocks of code into functions. If you want terminal integrated into your text editor with highlighting and LSP support, so be it. I want an IDE with rich refactoring tools, code analysis and good completion, database viewing/modeling support, good build tools support, good UI for git and git-diff, good test and code coverage support. I don't want your semi-IDE, bloated with hundreds of bugged third-party plugins, which I must spend a week on to configure and merry with each other before using.
JUST STOP this crap and let people use the tools they are proficient/comfortable/productive with.18 -
When you have to edit a 100+ line method but you discover that it has 0 test coverage.
Feels bad :/5 -
> colleague: My file has 79.25% of unit testing coverage
> supervisor: you're almost there! One final effort and you'll get that 0.75%!
Seeing someone this fucking dense is physically frustrating even when I'm not involved3 -
gradle is infuriating.
firstly there are so limited resources to understand how it's building a java/android code. everything happens by magic and hit+trial
secondly the plugins and the tasks works in mysterious ways. sometime they work when applied in the project root's gradle file, other times they work when applied in module's gradle file, nd other times they need configuration at both levels.
then there are gradle tasks like build ,test, assemble , clean etc. these are less of an action and more of an alias to run a bundle of actions.
then we have 3rd party plugins which attach themselves to these "fat-actions" and run before/after them
and finally we have the fuckup from the java world where the only available code coverage plugin is jacoco and IT FUCKING SUCKS!!! it is a test environment plugin, it should impact test tasks , but somehow it's fucking with the assemble taskin such a manner, that the jars ans aar files generated via plugin are giving runtime errrors. yes , runtime! as if we are back in the messed up js world of "everything is good unless running live"
even if it was a compile time eeror, i would have considered. but runtime?!! fucking runtime error?! i barely understand this shit, there is absolutely no info available as to which classes are being used to create a build and how, and i am supposed to fix this? wtf?!4 -
Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.
Little backstory. Starts with a question.
What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?
Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.
Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.
Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.
I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.20 -
My fellow developer was given a responsibility of writing unit test cases.
And instead of mocking the db calls he ended up making actual calls to db and adding realtime data to firestore everytime a test runs. Also he used mocha for the same. When i told him that we need to mock the db calls he said he will use sinon.js for the same and for code coverage his plans were to use istanbul.
I was like FUCKKKKKKK. , why the fk you aren't using jest. I mean whyyyyyyyy. WHAT THE FK4 -
You can have the best test coverage - even building your own fuzzing framework on the way.
You can have top notch devs adhering to state of the art development processes.
You can have as big a community and as well-funded a bugbounty program as you want...
All of that doesn't matter if you have chosen the wrong language:
https://googleprojectzero.blogspot.com/...
This would just have been an out-of-bounds exception instead of a buffer overflow using an attacker-controlled payload in any memory-safe language.
Language choice matters!
Choose wisely!13 -
Let's exclude some files from our coverlet coverage test!
Sure! That's easy, just remember to pass this super short, understandable, and rememberable command-line argument:
-- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.ExcludeByFile="**/myFile.cs/**"
You're fucking kidding me, right?
It's 2022 and tools are still using PowerShell syntax... just kill me1