#1 learn how to use debugger
#2 always cover your code with unittests

I have to refactor code from an intern. He's VERY lucky that he already left the company.

If I'd say he programms like the first human that would be very insulting to that first human.

It looks like code at first sight, but when you try to understand what he was doing to achieve his goal you get a brainfuck. Duplicate code, unused code, dumb variable names like blRszN.

He wrote unittests like "expects Exception to be thrown or Server returns Statuscode 500".
Yes, Exception, the generic one.

THESE FUCKING TESTS ARE GREEN BECAUSE YOU DID NOT ACTUALLY TEST SOMETHING.
GREEN IN THIS CONTEXT MEANS: YOUR PRODUCTION CODE IS A BIG PILE OF SHIT.

I already removed 2 bugs in a test which caused another exception than the "expected" one and the test does still not reach the actual method under test.

Dumb fucktard.

The sad thing: The fuckers who did the code reviews and let this shit pass are still here writing code.

We've had a bunch of flaky tests in our repo for a while now that no one could be bothered to fix; we'd just re-run ci until it's green. Today I looked into it and I was inspired to make this meme, because I lived through it.

Adding logs to investigate just lowered the fail rate making investigation more difficult. I do have an idea of what it might be though so, we'll see tomorrow.

So lets see if i can get this devrant stuff right.

So a couple of years ago i worked for this company, where i worked in datawarehousing and business intelligence. I was in my 3rd year of working as a software engineer and was full of ideas, motivation and just wanted to do cool stuff.

Anyway, after the first couple of months of working where i learned what they actually wanted to achieve, i got some ideas on how to improve the workflow. They were just simple things, like updating our IDE (we were working with a very old Visual Studio version), getting useful editors, using some more modern ideoms like unittests, continous integration, etc. Simple stuff really.

So in my endless naiveness i went to my supervisor and told him my ideas. He was not particularly interested in my ideas and cut me off somewhere in the middle and said that he would talk to his boss.

So a couple of weeks after that (nothing happened), i went to him again and asked about it.
M:" Hey Bossman, have you thought about my ideas?"
B:"Yes."
M:"And?"
B:"We won't do them."
M:"None of them?"
B:"No."

So at this point i was a bit bummed out, but surely he has a good reason right? So i asked why.

M:"Why?"
B:"Well, because we always have done it the way we do it now."

I think i had a bit of a blank stare at that point, because he looked at me funny. If we would do things like we always have done them, we would be still in the stone age you moron.

God i hate it when people say stuff like that.

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!

In the last one and a half days I optimized our Angular UnitTests. There‘re written with Karma and Jasmine. Before the optimization they needed ten minutes for around 400 tests. Now the same tests are executed in 12 seconds.

2 things I'm working on now:

#1 a personal project I am hoping to commercialize and turn it into my moneymaker. Hoping it'd at least be enough to pay the bills and put food on my table so I could forget 9/5 for good. But it has a potential of becoming a much, MUCH bigger thing. This would need the right twist tho, and I'm not sure if I am "the right twister" :) We'll see.

#2 smth I'm thinking of opensourcing once finished -- a new form of TLS. This model could be unbreakable by even quantum computing once it's mature enough to crack conventional TLS. I'm probably gonna use md5 or smth even weakier - I'm leveraging the weakness of hashing functions to make my tool stronger :)

I mean how long can we be racing with more powerful computers, eh? Why not use our weakneses to make them our strengths?

Unittests are already passing, I just haven't polished all the corner-cases and haven't worked out a small piece of the initialization process yet. But it's very close

* Ctrl+Shift+F to find all "assert" in solution...

Matching lines: 0 Matching files: 0 Total files searched: 1504

* Bang head on table

* Flip Table

* Start writing unit tests

> Run 'All Tests' with Coverage

No tests failing
Coverage >95%

Hell yeah! I've tasted TDD and I don't want to look back!

today, thanks to everyone else being tied up in meetings and forgetting to invite me to those meetings, i actually had a pretty zen day of refactoring and reviving old unit tests that no one ever seemed to know why they didn't work and so they were just skipped over.

Fucking fuck sonarcloud and everything about it. Part of the build pipeline for us to deploy code is to ensure that 90% of the code is covered by a unit test. Great in theory, horrible in practice. You think you've written enough tests that actually add value and test a valid piece of functionality but NO, sonarcloud throws a fucking fit because you're at 89.888 then your branch is going nowhere. Because everyone else gets to this stage and writes just enough tests to get the coverage to 90.01% then it becomes a stand off of who will break first; the code coverage threshold or your mental state.

I’ve been bashing my head against a project for the past 8 weeks. The project creates a PDF pulling data from multiple APIs, scrapes and private DBs and plots charts using Plotly. We built it with Python, wkhtmltopdf and Celery+Redis. The input is an excel with a list of up to 5 influencers to analyse and compare. Runs on demand on a Linux machine and each report takes around 20 mins to generate. The project has no unittests so the only way I can check everything works is by running a bunch of different inputs. Even though you test 10 inputs (taking you more than a day), there is a high chance something goes wrong on the 11th input. I’m thinking that the only way to fix this mess is to go back to the drawing board and plan yet another refactoring to add unittests everywhere. What do you guys think?

One of our intern's mind

27.8 + 27.2 = 54.10

🤣🤣
I show this in test case expectation

How the fuck am I supposed to fucking keep working if these fucking clowns add mandatory peer code review and passing build gating on main repositories (which I completely agree with to be fair) but they don't fucking review pull requests at all? For fuck's sake, am I the only one that reviews them seriously and promptly in this shit ass fuck company? I follow all the recommended guidelines so don't bullshit me with "iT iS nOt FuN tO rEvIeW pUlL rEqUeStS", do your job or just remove yourself from the fucking gating process, you worthless admin ass crust.

And don't get me started on fucking builds that fail randomly because some worthless shit bucket added unstable networking tests as unittests somehow, making your pull request get auto-disapproved by peers upon failure.

I got so many pending pull requests and management won't do fuck all about it because they won't force people to do their job by fear of pushing them around and get HR complaints that I am tempted to simply give up and just start playing videogames.

Dear Windows,

you done fucked it up!
I had a god damnit run, finishing the last mammoth task of our sprint.
Then, i decided to take a 3 minutes bio break.
Came back to my machine just to realise that this little OS bitch sneaked up on me, used the few seconds of my break to do a unholy, reboot of doom and damnation.
As a result, my virtual machine dropped it's php-storm settings...
I lost my precious focus on the task and my last nerves to figure out the correct settings again.

To cut a long story short.
We missed the aim of the Sprint.
The Sprint failed and i got a half-baked module.
At least, all the complicated businesslogic is proper covered by unittests.

Why does Bitdefender always have to delete my shit? I just want to compile some code!
link.exe? Defenetly malware, I should delete it for the 20th time! You want to run some unittests? No, that's malware, better block this too.

I started a new job, got through on-boarding and took my first ticket. Made my modification to the code base and the tests fail .. each time I run them .. on different tests .. randomly.

What the hell have I gotten myself into?

Confession - Testdriven UnitTests
First of all, I regret all and wish there would be no SQL Scripts but an external tool to analyze data, but the project grew hysterically and when I joined the sh*t had already been established...
I had to test some SQL Scripts. As there is no real UnitTest framework which is under development/gets support, the whole suite is kinda buggy.
So I had my script, and had the required input + expected output, but the UnitTest always failed. So I manipulated the framework parameters until the test finally passed.
Shame on me and on the project, but atleast there are tests now...

I wanted to fix ugly unittests of parser's function that uses some shitty workaround instead of intended unittest.mock.mock_open, but it turns out mock_open cannot mock different content for each file. Cause you know, noone needs it anyway.

Do you guys take time to properly name your Unit tests ?

I kinda feel it's waste of time. (There are comments with description of the test tho)