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
-
29-year veteran here. Began programming professionally in 1990, writing BASIC applications for an 8-bit Apple II+ computer. Learned Pascal, C, Clipper, COBOL. Ironic side-story: back then, my university colleagues and I used to make fun of old COBOL programmers. Fortunately, I never had to actually work with the language, but the knowledge allowed me to qualify for a decent job position, back in '92.
For a while, I worked with an IBM mainframe, using REXX and EXEC2 scripting languages for the VM/SP operating system. Then I began programming for the web, wrote my first dynamic web applications with cgi-bin shell and Perl scripts. Used the little-known IBM Net.Data scripting language. I finally learned PHP and settled with it for many, many years.
I always wanted to be a programmer. As a kid I dreamed of being like Kevin Flynn, of TRON - create world famous videogames and live upstairs my own arcade place! Later on, at some point, I was disappointed, I questioned my skills, I thought I should do more, I let other people's expectations make feel bad. Then I finally realized I actually enjoy a quieter, simpler life. And I made peace with it.
I'm now like the old programmers I used to mock 30 years ago. There's so much shit inside my brain. And everything seems so damn complex these days. Frameworks, package managers, transpilers, layers and more layers of code. I try to keep up. And the more I learn, the more it seems I don't know.
Sometimes I feel tired. Yet, I still enjoy creating things and solving problems with programming. I still have fun learning. And after all these years, I learned to be proud of my work, even if it didn't turn out to be as glamorous as in the movies.31 -
So there is this girl who was trying to be cute and wrote a mock C code for me :
She wrote :
If(existence=disapointment)
printf("kill self");
else
printf("what else??");
And without hesitating I told her that her code had a fault in it and it would always print "kill self" no matter what the level of disappointment is. And asked her to fix it.
The way she fixed it was probably best described as the situation when you have no idea what you are doing and you don't try to understand either. (or was simply passive aggressive) :
If(existence=disapointment)
printf("kill self");
else
printf("kill self");
Honestly though I hope she was being passive aggressive because boy do I pity people who confuse between '=' and '=='12 -
tl;dr: Bossmang blaming my code for a database connection issue thrown from outside of my code. Bossmang doesn’t listen. Bossmang doesn’t want to believe it’s a connection issue.
———
Bossmang: The code you wrote is causing insane spec failures in the release branch! It’s hard to follow because it’s so insane, but the cause is your code not properly handling undefined settings! Look at this! <spec>
Me: Specs pass on my machine. I ran it with both a set and nil value. <screenshots>
Bossmang: It works when you set it to nil.
Me: But a setting that doesn’t exist returns nil? <screenshot>
Bossmang: Not seeming to.... So this is the spec failure from the release: “No connection pool with id primary found. <stacktrace that starts outside of my code>”
Me: ... That’s a DB connection error. It’s also being thrown outside of my code, and from a `super` call to Rails.
Bossmang: But <unrelated> and <unrelated> and <other spec> is failing, and if I set the version, it has <other failure> instead! That calls your code first.
Me: It’s a database error. Also: <explains probable, unrelated cause of other failures, like someone didn’t mock a fucking external api call>
Bossmang: But if I restore a DB backup, it fails again.
Me: Restoring uses a dB connection, which could be exhausting the pool depending on the daemons you have running.
Bossmang: perhaps.
...
Bossmang: I still think it’s related to spec ordering.
🤦🏻♀️🤦🏻♀️🤦🏻♀️🤦🏻♀️🤦🏻♀️
This is tiring.12 -
I've seen several rants about dumb/useless teachers, college and the CS degree studies; today is a good day to vent out some "old" memories.
Around two semesters ago I enrolled in a Database seminar with this guy, a tall geek from the 80's with a squeaky voice, so squeaky mice could had an aneurysm if they listened to him.
Either way this guy was a mess, he said he was an awesome coder, that we were still "peasants" when it came to coding, that relational databases had nothing on him since he was an awesome freelancer and did databases every day, that we had to redo the programming course with him and with his shitty, pulled out of the ass own C++ style guide with over 64 different redacted rules.
He gave us sample code of "how it should be done" in Java...it ain't my favorite language but fuck me a fucking donkey could have written better code with his ass!! He even rewrote Java's standard input function and made it highly inefficient. He still wrote in a structural paradigm in OOP languages! And he dared to make this code reviews were he would proyect someone's code and mock it in front of the class as he took off points, sometimes going to the negative realm (3,2,1,0,-1...)
But you know what's shittier? That he actually didn't even attend, 90% of the time, it was literally this:
> Good morning class
> Checks attendance. . .
> I'll be back, I'm going to check in...
> 1 hour 45 minutes later (class was 2 hrs long) - comes back
> do you have any doubts?
> O.o no...? I'm ok.
> We're done
Not only that, he scheduled from 4 to 17 homeworks throughout the week, I did the math, that was around 354 files from everyone; of course he didn't check them, other students from higher semesters did and they gained each point taken from students making students from lower semesters get the short end of the stick.
How did I pass? He didn't understood my code or database schema and he knew he couldn't fail me as he had no ground to stand on.
Thanks for listening, if you got to the end of this long ass post and had a similar experience I'd love to read it.
13 -
The lead dev left the company two weeks ago. His last hurrah involved committing a bunch of complicated code into our API. The code he writes is generally overly coupled but this particular code is INSANE.
It is so coupled that the tests for it almost mock the entire application end to end. I only found this heap of garbage when the deployment tests were hung after I made a simple change in a totally unrelated file. THEY DIDNT FAIL. JEST GOT INTO A STATE WHERE IT CANT CONCLUDE AND HAS NO ERROR MESSAGES. We are taking about entirely different parts of the code. As far apart in the code as it can get. It took six hours of playing Sherlock Holmes to figure out what was breaking.
He got the most junior developer to approve the garbage PR as well.26 -
I’m back for a fucking rant.
My previous post I was happy, I’ve had an interview today and I felt the interviewer acted with integrity and made the role seem worthwhile. Fuck it, here’s the link:
https://www.devrant.io/rants/889363
So, since then; the recruiter got in touch: “smashed it son, sending the tech demo your way, if you can get it done this evening that would be amazing”
Obviously I said based on the exact brief I think that’s possible, I’ll take a look and let them know if it isn’t.
Having done loads of these, I know I can usually knock them out and impress in an evening with no trouble.
Here’s where shit gets fucked up; i opened the brief.
I was met with a brief for an MVP using best practice patterns and flexing every muscle with the tech available...
Then I see the requirements, these fucking dicks are after 10 functional requirements averaging an hour a piece.
+TDD so * 1.25,
+DI and dependency inversion principle * 1.1
+CI setup (1h on this platform)
+One ill requirement to use a stored proc in SQL server to return a view (1h)
+UX/UI design consideration using an old tech (1-2h)
+unobtrusive jquery form post validation (2h)
+AES-256 encryption in the db... add 2h for proper testing.
These cunts want me to knock 15-20h of Work into their interview tech demo.
I’ve done a lot of these recently, all of them topped out at 3h max.
The job is middling: average package, old tech, not the most exciting or decent work.
The interviewer alluded to his lead being a bit of a dick; one of those “the code comes first” devs.
Here’s where shit gets realer:
They’ve included mock ups in the tech demo brief’s zip... I looked at them to confirm I wasn’t over estimating the job... I wasn’t.
Then I looked at the other files in the fucking zip.
I found 3 of the images they wanted to use were copyright withheld... there’s no way these guys have the right to distribute these.
Then I look in the font folder, it’s a single ttf, downloaded from fucking DA Font... it was published less than 2mo ago, the license file had been removed: free for Personal, anything else; contact me.
There’s no way these guys have any rights to this font, and I’ve never seen a font redistributed legally without it’s accompanying licence files.
This fucking company is constantly talking about its ethical behaviours.
Given that I know what I’m doing; I know it would have taken less time to find free-for-commercial images and use a google font... this sloppy bullshit is beyond me.
Anyway, I said I’d get back to the recruiter, he wasn’t to know and he’s a good guy. I let him know I’d complete the tech demo over the weekend, he’s looked after me and I don’t want him having trouble with his client...
I’ll substitute the copyright fuckery with images I have a license for because there’s no way I’m pushing copyright stolen material to a public github repo.
I’ll also be substituting the topic and leaving a few js bombs in there to ensure they don’t just steal my shit.
Here’s my hypotheses, anyone with any more would be greatly welcomed...
1: the lead dev is just a stuck up arsehole, with no real care for his work and a relaxed view on stealing other people’s.
2: they are looking for 15-20h free work on an MVP they can modify and take to market
3: they are looking for people to turn down this job so they can support someone’s fucking visa.
In any case, it’s a shit show and I’ll just be seeing this as box checking and interview practice...
Arguments for 1: the head told me about his lead’s problems within 20mn of the interview.
2: he said his biggest problem was getting products out quickly enough.
3: the recruiter told me they’d been “picky”, and they’re making themselves people who can’t be worked for.
I’m going to knock out the demo, keep it private and protect my work well. It’s going to smash their tits off because I’m a fucking great developer... I’ll make sure I get the offer to keep the recruiter looked after.
Then fuck those guys, I’m fucking livid.
After a wonderful interview experience and a nice introduction to the company I’ve been completely put off...
So here’s the update: if you’re interviewing for a shitty middle level dev position, amongst difficult people, on an out of date stack... you need people to want you, don’t fuck them off.
If they want my time to rush out MVPs, they can pay my day rate.
Fuuuuuuuuck... I typed this out whilst listening to the podcast, I’m glad I’m not the only one dealing with shit.
Oh also; I had a lovely discriminatory as fuck application, personality test and disability request email sent to me from a company that seems like it’s still in the 90s. Fuck those guys too, I reported them to the relevant authorities and hope they’re made to look at how morally reprehensible their recruitment process is. The law is you don’t ask if the job can be done by anyone.6 -
"I'm almost done, I'll just need to add tests!"
Booom! You did it, that was a nuke going off in my head.
No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.
When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"
Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.
So let it be said:
- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.
Because then you suddenly have to mock away a http service and deal with zip files in your test cases.
The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.
In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.
Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.
That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.
Sidenote:
It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)8 -
Don't you hate it when your co-worker does dumb things, but thinks it's the "clean code" way?
The following is a conversation between me and a co-worker, who thinks he's superior to everyone because he thinks he's the only one who read the Clean Code series. Let's call him Bill.
Me: I think the feature we need is quite simple, our application needs to call this third party API, parse the response and pass it to the next step. Why do you need to bury everything under an abstraction of 4 layers?
Bill: bEcAuSe It'S dEcOuPlInG, aNd MaKe ThE cOdE tEsTaBlE
Me: I don't know man, you only need to abstract the third party api client, and then mock it if you want. Some interfaces you define makes no sense at all. For example, this interface only has 1 concrete implementation, and I don't think it will ever have another. Besides, the concrete implementation only gets the input from the upper layer and passes it down the lower layer. Why the extra step? I feel like you're using interface just for the sake of interface.
Bill: PrOgRaMmInG tO iNtErFaCe, NoT cOnCrEtE iPlEmEnTaTiOn!!!
Me: You keep saying those words, I don't think they mean what you think they mean. But they certainly do not mean that every method argument must be an interface
Bill: BuT uNcLe BoB blah blah blah...
Me: *gives up all hope*14 -
pms always tell the higher ups that I"don't have passion". I don't know how to show passion for their photoshop mock ups, one line requirements with no definition of done, their talking for hours about "leveraging" and name dropping about the top brass they are schmoozing with. I just ask if we are going to show our MVP to real users and she morphs to the bride of chuckie. I say we ought to pair program and she says it cost double to make a feature. Testing and code reviews are taking too much time but they hover over your shoulder while you try to fix a "mission critical bug" that occurs because they wanted us to skip practices that could have prevented the bug. Woo I feel better now!2
-
Gender Bending For Fun and Profit.
I love how in the 'make your avatar' area, if you select female, and then click facial hair, theres nothing to select from.
Like a massive fuck you to every gender bending "down with meritocracy" purple haired dicksniffer in sanfran.
Also I'm sorely disappoint for desk items, theres no
1. giant dildos
2. anime figures/weeb shit
3. mini monoliths (I asked the site devs about this, they replied "we can't do that dave.")
4. a shirtless option for my female avatar
5. edgy scrolling numbers and code, like in the matrix
6. hoodies. They're the modern leather jacket.
7. Big nasty gnarly biker beard which I'm currently in the process of growing. How am I supposed to intimidate other anonymous cowards and mock them over the size of their beard compared to my own avatar's e-beard size? It's quiet girthy and lengthy, I assure you!
This is completely unrelated, but I thought devducks were like quick one-off debug sessions that could be bought from other devrant users.
I was disappointed when I discovered it was just merch.
On the otherhand I'm glad as fuck it's not. Site would be flooded by broken-english speaking goat humping dickheads.
How am I supposed to show off my ability to code with completely unrelated avatar change ups when no one will allow me to emasculate my avatar?16 -
One of our juniors was adding a feature and made a small mistake in one of their (copy-pasted) unit tests by forgetting to cast a return value of a mock
So he spent a ton of time changing the main code to do type checks, try/catching and error handling.
Poor soul realized the mistake in code review one day later2 -
i made a mock code that wouldn't close to prank my colleagues. this boy tried the x button and it didn't work, so he went for ctrl alt del and the pop up showed up to confirm and when pressing yes it still wouldn't close1
-
My designer just had an user interview where the user is a developer and my designer showed him the mock-ups of a no code tool that we are building, asking the dev for his input.
She literally had a session with a guy announcing him that we are building a tool that will put him out of work and moreover asked him for inputs so that we miss no use case.
And in another story, one of my dev lead decided to decommission an entire feature and replace it will a hacky solution because the devs in her team were not comfortable using the current design in their development stage. Hence, without user research, any strong use case, or considering business implications, she went ahead and drafted the entire approach on how to fuck everyone.
I am out of my honeymoon phase at my new org and I am scared. Shit scared.16 -
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.3 -
Being the only dev in charge of the project, makes you the one to be blamed for.
The God saviour, shiny armoured back end developer that joined the "team" (only me) to help into this new project Just Said in a meeting:
- "I wont code anything for this new project, I can't get the point of It"
So every meeting was
- "why feature X is not ready?"
- "I'm waiting the endpoint for It"
- "well, then mock It"
Now I fucking give up.
One month mocking things and "presenting" features that don't even exist. -
The "unit" in unit test does not mean your ENTIRE APPLICATION. Ever heard of scope!?
I am amazed how often people write overblown test setups, mock hundreds of unrelated services, just to test one tiny bit of logic.
That bit of logic could have been a pure function.
For that pure function you could write a dead simple unit test. Given that input, I expect that output. Nothing more, nothing less. (It helps even more if the pure functions only accepts primitives, like string and numbers, or very simple immutable value objects).
No I don't care that the service is used by another service, as your mocked interaction also doesn't test the service as a whole but you just assume the happy case most of the time anyway. You want to test the entire application? Let's not use unit tests for that but let's use a different kind of test for that (integration test, functional tests, e2e-tests).
If you write code in a way that easily allows for unit testing, your need to mock goes away.1 -
*lunch time*
Designer: we want to put these graphs on the landing page.
Me: ok, well they are pretty simple I can recreate them in about an hour with JS, and they will look better and be inter active...
PM: we don't have time for that just use the images from the mock up
Me: ok...
*5hrs & dozens of emails later...*
PM: the graph doesn't look quite right, can we just build it in code so it looks better? Oh and we need to have it to the client to review by end of day...
Me: ...1 -
It’s late, and stupid RSpec has decided to only mock calls to a particular method in some specs but not in others.
`allow(object).to receive(:method).with(resource_arg).and_return(“some\ntext”)`
Works in a few specs, but not the rest. Why? Who the fuck knows. Probably some shared state between specs that isn’t supposed to happen.
HAHA JUST KIDDING
After refactoring my specs to use unique ‘resource’ names for each call because I’ve had shared state issues before.
and after refactoring my model code to remove a lot of now-unused dependency injection (because maybe it was mocking a different object than got passed in?)
Guess what?
When creating my mock objects, I forgot to link them together. That’s it. A 14-character change. And suddenly they all pass.
Asdjklfajg.
Time for bed.3 -
Dear mother fucking Hiring Managers,
Just because you are mother fucking fortunate, have a mother fucking proper job , a mother fucking high pay , have mother fucking parents care for you, does not mother fucking mean that you can mother fucking mock those mother fucking not as fortunate as you mother fucking arse!
Some of us carrying family, surviving, we learn how to code without a degree. Just because I have to motherfucking care for my family and pay off the mother fucking loan , it doesnt mean I am mother fucking unless. You mother fucking mother fuckers go fuck your mother fucking mother fuckers is the mother fucking mother fuckers' mothers.
Where's the empathy or politeness? You fucking ridicule people's bad luck, soon your mother fucking arsehole will be one , you bloody mother fuckers!6 -
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?
🥲🫡5 -
New twist on an old favorite.
Background:
- TeamA provides a service internal to the company.
- That service is made accessible to a cloud environment, also has a requirement to be made available to machines on the local network so you can develop against it.
- Company is too cheap/stupid to get a s2s vpn to their cloud provider.
- Company also only hosts production in the cloud, so all other dev is done locally, or on production non-similar infra, local dev is podman.
- They accomplish service connectivity by use of an inordinately complicated edge gateway/router/firewall/message translator/ouija board/julienne fry maker, also controlled by said service team.
Scenario:
Me: "Hey, we're cool with signing requests using an x509 cert. That said, doing so requires different code than connecting to an unsecured endpoint. Please make this service accessible to developer machines and lower environments on the internal network so we can, you know, develop."
TeamA: "The service should be accessible to [cloud ip range]"
Me: "Yes, that's a production range. We need to be able to test the signing code without testing in production"
TeamA: "Can you mock the data?"
Me: "The code we are testing is relating to auth, not business logic"
TeamA: "What are you trying to do?"
Me: "We are trying to test the code that uses the x509 you provide to connect to the service"
TeamA: "Can you deploy to the cloud"
Me: "Again, no, the cloud is only production per policy, all lower environments are in the local data center"
TeamA: "can you try connecting to the gateway?"
Me: "Yes, we have, it's not accessible, it only has public DNS, and only allows [cloud ip range]"
TeamA: "it work when we try it"
Me: "Can you please supply repro steps so we can adjust our process"
TeamA: "Yes, log into the gateway and try issuing the call from there"
Me: (╯°□°)╯︵ ┻━┻
tl;dr: Works on my server -
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 ...5 -
A newly joined developer (who was supposed to be very senior) comes and asks me how to write a test cos for some reason the person didn't know how to mock.
In Java,
(same for any other implementation which has an interface)
Writes Arraylist list =.....
Instead of List list = Arraylist...
Deployed code (another engineer from another country helped to deploy since this new senior dev didn't have access yet.
But the new senior dev didn't update relevant files in production code which brought down the site for nearly an hour. Mistake aside, the first reaction from this new senior dev is 'WHY DIDN'T THE DEV THAT WAS HELPING DIDN'T DO THE FILE UPDATE?'
This was followed by some other complaints such as our branching stragies are wrong. When in fact the new senior dev made a mistake by just making assumptions on our git branching strategies and we already advised on correct process.
Out of all these, guess this is the best part. The senior dev never tested code locally! Just wrote code, unit test and send to QA and somehow the test passed through. I learnt this when I realised this dev... has not even set up the local environment yet.
I keep saying new but this Senior dev been around like 3 months! This person is in another team within our larger team but shares same code base. I am puzzled how do you not set up your environment for 3 months. Don't you ask for help if you are stuck? I am pretty sure the env is still not setup.
Am I over reacting or is this one disgusting developer who doesn't even qualify for an intern let alone a senior dev? It's so revolting I can't even bring myself to offer help.8 -
Developer just emailed our team a complaint that our logging assembly was resulting in their poor test coverage and they sent a change request to give them the ability to mock the underlying log provider (ex. from the event log to ‘something else’).
Looked at their tests, and they are testing whether or not the .Log was executed (on an exception, if the .Log method was not executed, the test failed), which seemed a bit worthless because we’ve already got coverage in our unit tests.
We had a meeting to discuss the issue.
Me: “I’m OK with changing the logging code if it’s necessary, but I want to understand why.”
DevA: “Logging errors is crucial to the database transaction. If someone removes the logging, the tests should fail.”
Me: “If someone removes the error logging on purpose, then they likely have an agenda and will remove the test validation too. It wouldn’t be an accident.”
DevA: “That’s not my problem. They will have to deal with HR.”
Me: “We purposely prevented someone from intercepting the logging just for that purpose. Your test code already covers the business rule, testing the logging seems out of place. That would like writing a test to make sure the System.IO.File.ReadAllText actually reads all the text from a file. You kinda assume a few smart Microsoft engineers already wrote tests for that.”
DevA: “Yea, I guess that would be silly.”
Got cc’ed an email a little bit ago from DevA to his boss..
“We’re not going to be able to change logging assembly. This may have some impact on our overall test coverage as those lines of code will not get testing coverage. You will have to let the DevMgr know we will not meet our test coverage goals.”
WTF!1 -
I recently built a Mock JSON based REST server, that can help you out with API testing and prototyping without having to write any code for the backend, feel free to try it out, and star the repository if you liked it :)
Link: https://github.com/ishank-dev/...3 -
You had two additional weeks to improve your project.
You could research different marketing strategies to increase revenue. You could add some new features to attract more users and ensure your existing users are satisfied. Finally, you could optimize performance to make your UI quicker.
But you’ve chosen to write some unit tests. Now that two weeks are gone, you got no new features, no performance improvements and no new marketing strategies while your competitors got them all.
Tests caught obvious bugs that can even be caught by static typing, but you by definition couldn’t write tests that’ll catch unpredictable bugs, so they are still present.
After six months you realize you have to rewrite a major part of your project because your project (surprise-surprise) has to chase market needs to stay relevant. Your tests are thrown into trash along with your old code.
“Having trouble with code quality? Write a lot of tests. And I mean a *lot*. Test every file in isolation. Mock as many imports as possible.
When you're done, your code will still be bad, but now your tests will make sure it's impossible to improve anything in any meaningful way.”12 -
If you have striggled a lot to find good diagram makers/editor. Here is the one.
draw.io is free online diagram software for making flowcharts, process diagrams, org charts, UML, ER and network diagrams.
Try it. Its open source. Even the code is open source, you can get the war and run it in you tomcat offline...
I am listing few type of diagram you can draw are
1. ER Diagram
2. UML Diagram
3. Business process workflows
4. Bootstrap components for mock screens
5. Wireframes
6. Floor plan
7. Network diagram
Many more...
Explore!!!
https://www.draw.io -
I can now leave freely without any regrets!
The slight misgivings I had about leaving this place over the toys they provide, is now gone because I re-realized that while this place adopts new tech, it doesn't adapt to it. So they have shiny tools but the people and processes won't change.
It seems to me that due to pressure to deliver, there is little thought/analysis behind any tech change.
They don't plan to change their wretched delivery pipelines. Everything will be same but on git. So no velocity gains, and same bureaucratic review request process. Such a waste. This attitude applies to their other tools too. They are using a unit test library to write tests that don't use mock. They are using modern languages but without modern idioms. It's like writing C code in C++. And of course theoretically we are agile but actually we're just a waterfall team with managers on our ass everyday and tighter release schedules.
Reminds me of @boombodies recent posts and discussion about business spaghetti reflecting in code.
There are possibly multiple reasons for these problems but I think a large part of it is a lack of empathy/mutual respect. Everyone's too insecure, noone cares for anyone but themselves and people just try to outwit each other. -
TFW the mock class has way more code than the real one.
Testing big infrastructures can be a pain...
Or maybe my team is just not so good at it.
My time spent:
Adding new feature to the real class 15%
Extending the mock with the same feature 55%
Writing tests 30%7 -
Yo dawg, I heard you like writing code for code you already wrote. So I made you write some mock functions so you can write code for code you already wrote!2
-
First thing Wednesday morning, fired up the macbook, opened vs code, ran the same unit tests that were passing last night, 1 failure! FML.
For some reason an Angular form that was valid with the same data last night isn't this morning. Probably some crappy date issue in the mock data1 -
When the PM has been letting a fresh faced graduate loose on a codebase without any code reviews and you come back to some cronenburg level horror in your now crippled project. But it LOOKS like the mock ups.... * internal screaming *
-
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?3 -
When I created stubmatic (a http mock application), we were using it in our internal project. First time when some other project expressed their interest, I was happy and eager to help.
So the person they sent for the training asked me his first question: "I followed all the steps, but It is not working"
I quickly checked his code and replied "you're using GET instead of POST method"
Then his second and last question about stubmatic was "why don't your code understand which method has to be used? Why should a client need to tell every time?"
Ummm... silence -
My team was asked to point to a mock service in our QA env. Standard procedure is to copy the line in our QA property file that has the service URL, comment one out, and change the other to the mock service. Then, push the code and deploy to QA.
What did someone do? He didn't touch the property file. He found where we were defining the configuration for our http requester, removed the property reference, and HARD CODED the mock URL.
Wait, it gets better. The mock service does not function the same way the real service does. We need to send an additional query param to the mock service (that has a value already being sent in a header) so they modified ANOTHER file where the actual request is being made.
He made the changes, deployed to QA, and didn't check in any code.
What is going to happen next time when we deploy to QA with the latest code? Oh look, we'll be pointing to the real service again.
I explained this to my architect, and included that this messed up mock service they were calling is our 2nd mock service (no idea why they made a new one) and he simply deleted the stupid 2nd mock service. Screw that!
And...now requests to QA don't work 😂 -
How do you implement TDD in reality?
Say you have a system that is TDD ready, not too sure what that means exactly but you can go write and run any unit tests.
And for example, you need to generate a report that uses 2 database tables so:
1. Read/Query
2. Processor logic
3. Output to file
So 1 and 3 are fairly straightforward, they don't change much, just mock the inputs.
But what about #2. There's going to be a lot of functions doing calculations, grouping/merging the data. And from my experience the code gets refactored a lot. Changing requirements, optimization (first round is somewhat just make it work) so entire functions and classes maybe deleted. Even the input data may change. So with TDD wouldn't you end up writing a lot of throwaway code?
A lot of times I don't know exactly what I want or need other than I need a class that can do something like this... but then I might end up throwing the whole thing out and writing a new one one I get a clearer idea of what i or the user wants or needs.
Last week I was building a new REST API, the parameters and usage changed like 3 times. And even now the code is in feasibility/POC testing just to figure out what needs to be used. Do I need more, less parameters, what should they be. I've moved and rewritten a lot of code because "oh this way won't work, need to try this way instead"
All I start with is my boss telling me I need an API that lets users to ... (Very general requirements).10 -
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 -
When do the front-end developers get the APIs.?
How does the communication between front-end and back-end works.?
I work in a startup and I'm getting the feeling that this communication is way off the place. Many-ier times we have to wait for weeks for the API to come. Till then, we build mock data structures and implement it. The API gives us more and less exactly what we need. And you can guess it sometimes the structure gets changed in such a way our front end code gets to be refactored.
Is it the correct way.? The whole mock data structures and wait for the API thing. One of my colleagues says, "It's much better if we get some part of API first and integrate it progressively".2 -
Looking at jest errors and loads of GitHub and StackOverflow issues, it's no surprise that people claim they don't like testing.
Maybe they would if we got our tooling right.
import { foo } from 'bar';
Nah, that's an unexpected token, jest does not like this syntax.
Using require, like in jest's getting started tutorial isn't compatible with my existing JS libraries exports.
Adding type: "module" in package.json just makes another error message appear instead.
Fucking developer experience!
Why bother with unit tests at all?
How come PHP is 10 years superior to JS when it comes to code quality, unit tests, and static code analysis?
I don't even care about "ES modules". I don't want to "mock" anything either. All I want to do is import a handful of JavaScript functions into another file.
Overengineered web dev stack sucks!3 -
WHY DO YOU MOCK ME SO?!?
..... Where ever you are... I will find you, add I will eradicate your code breaking behavior....... Eventually....
GODDAMNEFFFING VBA -
Critical Tips to Learn Programming Faster Sample:
Be comfortable with basics
The mistake which many aspiring students make is to start in a rush and skip the basics of programming and its fundamentals. They tend to start from the comparatively advanced topics.
This tends to work in many sectors and fields of Technology, but in the world of programming, having a deep knowledge of the basic principles of coding and programming is a must. If you are taking a class through a tutor and you feel that they are going too fast for your understanding, you need to be firm and clear and tell them to go slowly, so that you can also be on the same page like everyone else
Most often than not, many people tend to struggle when they reach a higher level with a feeling of getting lost, then they feel the need to fall back and go through basics, which is time-consuming. Learning basics well is the key to be fast and accurate in programming.
Practice to code by hand.
This may sound strange to some of you. Why write a code by hand when the actual work is supposed to be done on a computer? There are some reasons for this.
One reason being, when you were to be called for an interview for a programming job, the technical evaluation will include a hand-coding round to assess your programming skills. It makes sense as experts have researched and found that coding by hand is the best way to learn how to program.
Be brave and fiddle with codes
Most of us try to stick to the line of instructions given to us by our seniors, but it is extremely important to think out of the box and fiddle around with codes. That way, you will learn how the results get altered with the changes in the code.
Don't be over-ambitious and change the whole code. It takes experience to reach that level. This will give you enormous confidence in your skillset
Reach out for guidance
Seeking help from professionals is never looked down upon. Your fellow mates will likely not feel a hitch while sharing their knowledge with you. They also have been in your position at some point in their career and help will be forthcoming.
You may need professional help in understanding the program, bugs in the program and how to debug it. Sometimes other people can identify the bug instantly, which may have escaped your attention. Don't be shy and think that they'll make of you. It's always a team effort. Be comfortable around your colleagues.
Don’t Burn-out
You must have seen people burning the midnight oil and not coming to a conclusion, hence being reported by the testing team or the client.
These are common occurrences in the IT Industry. It is really important to conserve energy and take regular breaks while learning or working. It improves concentration and may help you see solutions faster. It's a proven fact that taking a break while working helps with better results and productivity. To be a better programmer, you need to be well rested and have an active mind.
Go Online
It's a common misconception that learning how to program will take a lot of money, which is not true. There are plenty of online college courses designed for beginner students and programmers. Many free courses are also available online to help you become a better programmer. Websites like Udemy and programming hub is beneficial if you want to improve your skills.
There are free courses available for everything from [HTML](https://bitdegree.org/learn/...) to CSS. You can use these free courses to get a piece of good basic knowledge. After cementing your skills, you can go for complex paid courses.
Read Relevant Material
One should never stop acquiring knowledge. This could be an extension of the last point, but it is in a different context. The idea is to boost your knowledge about the domain you're working on.
In real-life situations, the client for which you're writing a program for possesses complete knowledge of their business, how it works, but they don't know how to write a code for some specific program and vice versa.
So, it is crucial to keep yourself updated about the recent trends and advancements. It is beneficial to know about the business for which you're working. Read relevant material online, read books and articles to keep yourself up-to-date.
Never stop practicing
The saying “practice makes perfect” holds no matter what profession you are in. One should never stop practicing, it's a path to success. In programming, it gets even more critical to practice, since your exposure to programming starts with books and courses you take. Real work is done hands-on, you must spend time writing codes by hand and practicing them on your system to get familiar with the interface and workflow.
Search for mock projects online or make your model projects to practice coding and attentively commit to it. Things will start to come in the structure after some time.4 -
Guidewire is the work of satan. It is the worst framework I have ever worked with. OOTB code is full of antipatterns, creating gui is a pain, and it has its own language that is a pure joke. Every task I had had to have some sort of workarounds. You cant junit test it. Entity builders are a mess and you cant mock gosu classes. I hate it so much.
Top Tags
Weekly Rant
View