It happened to one of my friend at work place.

So my friend is a UI developer and was working on a super critical project with very tight deadline. He was waiting for design team to give him mocks and web api team for giving Apis, so he can start his work. Now there are 4 days left for deadline and none of the parties are ready with their work, and my friend is sitting idle. Management is getting anxious day by day. So one program management lady called him the weak link in the standup meeting and started putting blame on him for the delay in the project. Guy tried to explain that it's not his fault and he is stuck. But that lady was not in a mood to listen.

Now come the next day, in morning he got the design ready and complete Apis from other teams. That day he missed the standup meeting, worked whole night and completed the work with two days remaining for deadline. He went to standup meeting after completing the work, and when the turn came for him to give his status, he started with "the weak link has finished the work". There was a pin drop silent in the room. He continued to give his update like this for next couple of days. And finally that lady was forced to apologize in meeting room by him.

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.

Let me preface this by saying I'm not a designer.

While I can make individual bits of a site look good, and I'm actually pretty skilled with CSS/Sass, overall design completely escapes me. I can't come up with good designs, nor do I really understand *why* good designs are good. It's just not something I can do, which feels really weird to say. but it's true.

So, when I made the Surfboard site (that's the project's internal name), I hacked everything together and focused on the functionality, and later did a branding and responsive pass. I managed to make the site look quite nice, and made it scale well across sizes/devices despite being completely new to responsiveness. (I'm proud, okay? deal.)

After lots of me asking (in response to people loudly complaining that the UI doesn't have X feature, scale properly on Y device, and doesn't look as good as Z site), the company finally reached out to its UI contractor who does their design work. After a week or two, he sent a few mockups.

The mockups consisted of my existing design with a darker background, much better buttons, several different header bars (a different color) with different logo/text placements, and several restyled steppers. He also removed a couple of drop shadows and made some very minor styling changes (bold text, some copy edits). Oh, he also changed the branding colors. Nothing else changed. It's basically the same exact site but a few things look a little better. and the branding is different.

My intermediary with the designer asked for "any feedback before finalizing the designs" -- which I thought odd because he sent mocks for two out of the ten pages (nine plus a 404 page). (Nevermind most of the mocks showed controls from the wrong page...).

So, I typed up a full page of feedback. Much of it was asking for specifics such as responsive sizing on the new header layout, how the new button layout would work for different button counts, asking for the multitude of missing pages/components, asking why the new colors don't match the rest of our branding, etc. I also added a personal nitpick about flat-looking controls because I fucking hate them. Everything I wrote was very friendly and professional.

... His response was full of gems. Let me share a few.

1. "Everything about the current onboarding site looks like a complete after-thought." (After submitting a design basically identical to mine! gg!)

2. "Yes [the colors match our current branding]." (No. They don't. I checked. The dark grey is different, the medium grey is different, the silver is different, the light blue is different. He even changed the goddamn color of the goddamn LOGO for fuck's sake! How the fuck is that "matching"?!)

3. "Appreciate the feedback [re: overlapping colored boxes, aka 'flat'], design is certainly subjective. However, this is the direction we are going." (yet it differs from the rest of our already-redesigned sites you're basing this off. and it's ugly as shit. gg again :/)

4. "Just looked at the 404 page. It looks pretty bad, and reflects very poorly on the [brand name] brand. Definitely will make a change here!" (Hey! I love that thing. It's a tilted, dotted outline of a missing [brand product] entirely drawn with CSS. It has a light gray "???" underlay and some 404 text inside. Everyone I showed it to, coworkers and otherwise, loved it. "Looks pretty bad". fuck you.)

I know I shouldn't judge someone so quickly, but what the fuck. This guy reminds me of one of those pompous artists/actors who's better than everyone and who can never be wrong, even while they're contradicting themselves.

just.
asfjasfk;ajsg;klsadfhas;kldfjsdl.

Writing more infrastructure than product.

Look, my application requests and transforms data from a single external API endpoint, it's just one GET request...

But I made an intelligent response caching middleware to prevent downtime when the parent API goes down, I made mocks and tests for everything, the documentation is directly generated from the code and automatically hosted for every git branch using hooks, responses are translated into JSONschema notation which automatically generate integration tests on commit, and the transformations are set up as a modular collection of composable higher order lenses!

Boss: Please use less amphetamine.

New developers(5-6 years experience) these days are so pathetic. They dont have any sense of code review. All they want is to put their opinion out without giving any thought.

I had a PR for review today which contains mock specification to match a regular expression and return the corresponding response

The regular expression I put was

104000(02|06|20|48)

Now, this guy comes and puts a comment that we could "simplify" as 104000\d{2}

I replied, the ending digits are not contiguous. The specific pair of digits have to match for these mocks.

Then this guy replied, then we could simplify as 104(0{4}(2|6)l0{3}(20|48)).

I said, I cannot understand how that is simplification. Why do we need such a complex regex to match something very straight forward.

And the guy replied, we should be writing proper regexes, otherwise we could just specify everything explicitly.

I was like WTF man. You try deciphering this next week without taking at least a minute to know which values are matched.

Anyhow, another senior person approved my PR, and I merged it.

Learning to code in Visual Studio with such lame examples that I literally have to minimize my screen so that no one mocks me. #beginnerproblems

Lets create a library.

Lets use that library in a project.

Lets wrap the library call in a wrapper functione to remove duplicate code.

Lets add an overloaded wrapper call that wraps the wrapper call that calls the library to partially undo the duplicate code removal.

Lets add another overloaded wrapper call that wraps the wrapper call that wraps the wrapper call that calls the library to partially undo the duplicate code removal.

How I love it. Not.

Sometimes redundancy makes sense, especially when it are two lines which make it obvious whats going on vs a single line that leads to a fuckton of overloaded wrapper functions.

Sheeesh.

Today in "code monkeys deserve divine punishment".

Another funny thing is creating a Helper class for Junit 5 tests, making it instantiable and adding to it all kinds of shit like testcontainer creation, applications instantiation, mocks, ....

... Then " crying " why the tests are so slow.

Yeah. Logic. Isolation of concerns, each test should be a stand alone complex.

But that would lead to redundancy... Oh no.

Better to create a global state god object.

Some devs... Really amaze me, especially when they argument in ways that makes one really wonder whether they are serious or just brain dead.

I'm getting really tired of those dumbass programmers that do not understand shit and then come to me when production breaks. (I am also a programmer, not really a DevOps engineer, but I'm the least worst at DevOps stuff, so it's my job...).

We're programming some kind of document management tool. Today we had a release, and one of the new features is to download all of your documents as a zip file, which is asynchronuously generated. When it's done, the user gets a mail with the download link to the zip file.

The feature works basically, but today it broke our production service, as somebody was running a test of it.

Turns out all the documents are loaded into memory to be zipped. So if you have 2 gigs of documents, a container with memory restrictions in that area will crash.

I asked the programmer who reported this «ops problem» to me, why he didn't just shit the files into a temp foler in order to zip them in there.

He told me that he wanted to do so, but did not know how to mock this for a unit test, and therefore went to the in-memory «solution», which was easier for him to mock.

For fuck's sake, unit tests and mocks are fucking tools, not ends in itself! I don't give a fuck about your pointless mocking code when the application crashes!

When I got to deal with such dumbasses, I'd prefer to mock those motherfuckers with a leaky bucket of liquid shit, which basically accomplishes the same task from my perspective: dripping shit all over the place and make everything suck as fuck.

Dear previous dev on this project,

I know that everyone loved you and still admires you for being so nice and having such a great knowledge. Please teach me your ways of achieving this level of popularity while writing big bowls of fucking flying spaghetti monster code with a bunch of hidden bugs and thousands of lines of unit tests that clearly never been used since it is literally impossible to run them thanks to missing mocks and overall bad design.

Teach me so I can become this person who shits big reeking piles in the office in front of everyone and even after leaving people still praise them for being exceptionally clean and sophisticated.

Always test your fucking mocks
I spent 3 weeks debugging every part of the application, except for the mock network connection. The mock network connection didn't trigger closing events on the sender side.

Unpopular opinion: unit tests are often overrated.

Although a well written test suite is almost essential in some parts of the application (I.E. business logic) I cringe when I see hundreds or thousands of line which “mocks” everything to test a micro service which just does CRUD operations on a database, in cases like that unit tests are just a waste of time because almost every operation involves a mock which may not behave like the real database and often needs to be rewritten when the code undergoes a huge refactoring. In these case a integration test suite is faster to write and way more helpful.

My boss: Write unit tests for this angular app
Also my boss: what do you mean it will take months to write the necessary mocks for our 177 specs
Also also my boss: why would you need to mock anything for a unit test
Also also also my boss: Just let each component import all the other real components, nevermind that that's an integration test and not a unit test

ideal sprint fallacy.
total days 10 , total hours(excluding breaks ) 8 hrs per day= 80 hrs per dev

code freeze day = day 8, testing+ fixing days : 8,9,10. release day : day 10
so ideal dev time = 7days/56 hr
meetings= - 1hr per day => 49 hrs per dev

- 1 day for planning i.e d1 . so dev time left . 6 days 42 hrs.
-----------
all good planning. now here comes the messups

1. last release took some time. so planning could not happen on d1. all devs are waiting. . devtime = 5 days 35 hrs.

2. during planning:
mgr: hey devx what's the status on task 1?
d: i integrated mock apis. if server has made the apis, i will test them .
mgr : server says the apis are done. whats your guestimate for the task completion?
d : max 1-2 hrs?
m : cool. i assign you 4 hrs for this. now what about task 2?
d : task told to me is done and working . however sub mgr mentioned that a new screen will be added. so that will take time
m : no we probably won't be taking the screen. what's your giestimate?
d : a few more testing on existing features. maybe 1-2 hrs ?
m: cool
another 4 hrs for u. what about task 3?
d : <same story>
m : cool. another 4 hrs for u. so a total of 12 hrs out of 35 hrs? you must be relaxed this sprint.
d : yeah i guess.
m cool.
-------
timelines.
d1: wasted i previous sprint
d2 : sprint planning
d3 : 3+ hrs of meetings, apis for task 1 weren't available sub manager randomly decided that yes we can add another screen but didn't discussed. updates on all 3 tasks : no change in status
d4 : same story. dev apis starts failing so testing comes to halt.
d5 : apis for task1 available . task 3 got additional improvement points from mgr out of random. some prod issue happens which takes 4+ hrs. update on tasks : some more work done on task 3, task 1 and 2 remains same.
d6 : task1 apis are different from mocks. additionally 2 apis start breaking and its come to know thatgrs did not explain the task properly. finally after another 3+ hrs of discussion , we come to some conclusions and resolutions
d7 : prod issue again comes. 4+ hrs goes into it . task 2 and 3 are discussed for new screen additiona that can easily take 2+ days to be created . we agree tot ake 1 and drop 2nd task's changes i finish task 2 new screens in 6 hrs , hoping that finally everything will be fine.

d8 : prod issue again comes, and changes are requested in task 2 and 3

day 9 build finally goes to tester
day 10 first few bugs come with approval for some tasks
day 11(day 1 of new sprint) final build with fixes is shared. new bugs (unrelated to tasks. basically new features disguised as bugs) are raised . we reject and release the build.

day 2 sprint planning
mgr : hey dev x, u had only 12 hrs of work in your plate. why did the build got delayed?

🥲🫡

Hey guys, so i got my first job, but there's this stupid problem there that i am having...there's this guy who makes fun of everybody and there are other two guys who laugh at his every joke whenever he makes fun of someone. He made fun of me too a few times, fun of my age, fun of my nose, fun of certain things i said, and those other guys laugh , and this is really frustrating and annoying. I am thinking of quitting..but i am not sure...should i quit for such a small reason? I dont like such people...i dont know what to do...i dont wanna complain to the HR for such a small thing and create more drama...kindly tell me what to do...i really get sad when he indirectly mocks me because of my age. I am a bit old, 31...and the others are in their twenties...please help, thanks

You may know I love to hate tests. Well not the tests actually, what I hate is the TDD culture.

DBMS schema in my app dictates a key can either have a value, or be omitted - it can't be null, and all queries are written with that in mind (also they're checked compile-time against schema). But tester failed to mock schema validation, inserted a bunch of null keys with mock data, actually wrote assertions to check those keys are null (even though they never should be), and wanted me to add "or null" to my "exists" queries.

No, we don't need more tests, and you're not smart with your "edge cases" argument. DBMS and compiler ensure those null values can never exists in our DB, and they're already well tested by their developers. We need you to stop relying on TDD so much you forget about the practical purpose of the code, and to occasionally break from the whole theoretical independent tests to make sure your testing actually aligns with third-party services some code uses.

And no, we don't need more tests to test your mocks, and tests to test those test, and yo dawg, I heard ...

If a frontend dev asks for screens, mocks, designs or whatever, all the company pushes for it and gives it to them, but if a backend dev asks for a set of input/output samples for a feature, the same people claim "its so hard to think about the cases"... Wtf are they thinking?

Not dev, but a perf-eng confidence boost.

Our company was hired by a client to onboard perf-testing process and do some perf-related go-live stuff. Basically, make sure the app meets the SLAs.

Our company mobilized some internal resources for the task. The had 3-4 months. 2 months later they realized they won't pull it off. What a shame...

When the threat of dropping the ball and losing the client and recommendations became very real, they engaged us. Half the time, half the resources, a worried and annoyed client who now wants to control the whole initiative.

During the first 2 meetings we get the general idea of what they have, what they want. We take some time to prepare a plan to make it on time. The client argues our plan, mostly because one of the main points was mocking downstream dependencies [integrations]. He asks, then demands to do it all with live integrations. We explain why this is an incredible risk and why we should do it the proposed way. He disagrees.

Alright then... Maybe he knows smth we don't. Let's do it the risky way...

A month later test results are far from the target. I did my best with app de-bottlenecking and fine-tuning. But since the live integrations do not deliver, they hide other bottlenecks. The initiative is stuck.

Finally, the client agrees to do it with mocking. But now there's no time left as it will take almost a month to prepare mocks...

The client agrees we should have done it our way from the start. They postpone the go-live and we carry out our testing and tuning the right way.

That was one expensive and long "I told you so". But it boosted our [perf team's] confidence to the top and beyond :)

don't tell us how to do our job, unless you do want extra expenses

I just reviewed a pull request with a test case like (pseudo code):

# Test MyService

const mock = createMock(myService.myMethod)
.whenCalledWith("foo")
.returns("bar");
assert(mock.myMethod("foo") === "bar"));

Why though? Why are we testing the mock? What is happening here? This test has no reason of being there instead of a fuzzy feeling that we now have unit test to lure us into a false sense of security.

I asked why we don't do an integration test. Response was: "They are slow."

Well, duh, but at least they would actually test something.

What do you gain by asserting that the mock is working the way you set it up?

Ugh! I feel so low and less motivated because I am unable to solve the interview practice questions really well.

This is fucking annoying. I am not sure what is that that I am lacking.

I got the framework. I have problem statements. I am practicing mocks. I got the feedback and I implemented it.

I have spent ~30 hours on this till now. Solved around ~20 cases, 10 of each category.

Should I now purely bet on luck? Maybe I'll take a break and submit the other companies case assignment to divert my mind.

I need to crack the interview and land the offer at all cost. There is no chance or scope for failure.

I'm building a desktop Java application, the build is running from 20 minutes and it keeps going... and people still mocks C++ for being slow in building

My pair partner and I managed to break every feature test written by our 16 strong team today while fixing a login form. Fixing other people's non-refactored rspec tests is not a pleasant experience lol

#Development Story:
No Size for iPad (only mocks are mobile and desktop)
Ambiguous on Close Button (size and position)

#Development:
Me: iPad size, should it be X?
Product Owner: Yes

#QA
QA: Close button is to Small, change to bigger
ME: (ok....)

#Product Owner Review
Product Owner: Close button to big, make it smaller, also iPad size is not that, is Y.

Me:

React Native testing is hair pulling.

Every test needs to have 100 different mocks in place and there are: 3 different methods to mock a function (mock, mockImplementation, and fn), 3 different types of query methods to get elements (get, find, and query), and 5 different selectors to query on (accessibility label, testId, accessibility hint, accessibility value, etc.)

And after reading all this, being diligent and learning the difference between stupid, synonymously-named functions which have wildly different side effects like "getByA11yHint" and "findByA11yHint" (ugh...), after all that, you write out a test with all the appropriate mocks and you want to do something simple and it beats you up all over again.

Button enabled or button disabled. Simple right? Logically the former is "expect(elem).toBeEnabled()" and the latter is "expect(elem).not.toBeEnabled()", right?

Wrong! You're an imbecile. Your tests will fail and never tell you that ".not.toBeEnabled()" and ".toBeDisabled()" don't do the same thing even though they look and sound exactly the same. Only the latter will work. The former makes all your tests fail. Where is this written in the docs? Nowhere?! Great!

👌😄🔫

Why are there so many testing framworks for JavaScript? Jasmine, mocha, buster ... and for spies, stubs and mocks, there is sinon and for assertions, there is chai. And oh you can record entire external api calls with nock and whatever else I forgot. I am a bit overwhelmed by this overambundancy of libraries. Writing tests is supposed to be easy.

All the professors I had didn't accept that I have already solid notions about the arguments in their course. I tried to explain I worked in some agency and they invested in employee knowledge but the tilts was embarrassing, they mocks you but systematically when you hit the highest score in the test they compliments for "how well I've studied" when I didn't spent one minutes on studying while I was engaged with more complex and training exams. I wish a degree where you can attend the exam without following the course if I'm already prepared.

This is my frontend tip of the day.
If you have a frontend that consumes an external API:
1) Retrieve the json responses from devtools
2) Save them in your project as json files (trim the data a bit if it's too long)
3) When starting your app with a special env var like MOCK_DATA, make your app mock the data and use your saved json data instead.

You can associate each response with an url regex.

The package fetch-mock mocks fetch really well, it lets through the urls that don't match anything.
This way you can incrementally add responses.

And voila, you have a mode where you have near instant page loads to test things manually, and you also have mocked data ready for testing eg, cypress.

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 frigging hate unit testing an AngularJS application. The amount of mocks you need to create just to test a a piece of code is unbelievable

Stubmatic: mocks and debug HTTP calls. Designed specially for testers.

In the kingdom of aws reigns the Owner of Products.
In his court many a vassal noble (or a "sre" as they are often called) delivers their tribute.
Wise ministers (called "analysts" in these here parts) advice the Owner of Products on how to instruct his sres and where to lead the kingdom.
Needless to say, in the court the blabber is endless and the egos of the courtiers, deservedly or not, are even larger.

But there is but one member of the court, leader of none but master of japes, who dares to mock not just the courtiers, but even the Owner of Products.
Tester the Jester, from the houses of Operations Research and Quality Assurance.

There is a unique relationship between a ruler and his jester. The jester mocks the ruler, with the most outlandish of propositions, with the most malicious interpretations of the ruler's orders, evidencing the most absurd (but mathematically viable) results of a plan.
The jester makes ridicule of the ruler's edicts... so that the Owner of Products may remain humble, without need to defer to any upstart courtier.
And, in a more subtile manner, the jester prevents any courtier from maliciously complying with the edicts of the ruler.
For all in the court have heard how the lowest among them voiced the preposterous interpretation... And dare not show themselves to be even lower.

TL;DR had an all-hands meeting of tech leaders with the allmighty PO. In the meeting there is this bloke who apparently spends all his time just fucking with the bigwigs' ideas. Dude is a department of one. It seems that his whole job is being an outlandish scenario simulator & sarcasm artist. I now have way more respect for this place.

Child mocks his father! Is it right ?

I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?

‪4 hours later and my code is finally working and as usual it was only one line causing everything but on the bright side I now now how to use mocks and spies ‬

Is it actually required to write unit tests in microservices?
every time i write them it feels like im just redundantly copying a method...
Dont get me wrong, im not against testing, I am using test environments, integration tests and mocks, but unit test seem kinda redundant to me.

time of weak blood.
a decaying sack of guts, old, bitter and dying rapidly mocks me for saying i'm lonely, stuck in the same prison, and he'll never be free, or know what being human feels like a day in his life before he dies.

I'm feeling guilty.
I've a lot of fun hearing the flautolence wich comes out from the mouth of my brain farters collegues in my university. I usually fake being a mediocre student who never worked nor programmed anything else except the stupid exercises related to the exams. Yesterday a collegue come out saying: WOAH, YOU'RE USING LINUX!
Good, nice deduction my dear Sherlock.
The best had to come.
The genius decided to mocks me up telling: YOU KNOW IF YOU TYPE sudo rm -rf / IN THE CMD YOU MAKE YOUR COMPUTER FASTER?
Before I processed that he's not serious i answered "no, rm just remov..." and I saw the beaten look in his eyes because the joke misersbly failed. So i proceeded: "hahaha, fun. Anyway i could rm -undo to fix the mess".
As soon i finished the sentence he ran on him laptop and boots up the VM to try...

when it takes more effort to writing a bunch of dumbass mocks and stubs so you can have an automated test, than it does to manually test, because you're too retarded to figure out how the fuck easymock is supposed to work, and being awful at your job, also fuck java imports and easymock for being difficult to work with

shout out to my coworkers for requesting more automated tests

can't wait till it all gets deleted anyway because we're going to delete the code we're testing

-> Change the signature of one function
-> Go around the entire codebase to add that one extra parameter every damn where
-> thank god for IDE's
-> tests still fail
-> realise that mocks are not captured in the previous exercise of combing through the codebase
-> #frustration

I have to mock an API for my tests. The mocks got so complicated, I basically have cloned the API at this point. Now I'm testing my mocks to make sure they work. I'm essentially writing tests for my tests. There's gotta be a better way to do this.