We tested each and every setter and getter, what can go wrong with integration?

> Last year wrote a unittest - I was asked to delete it
> no design patterns. Not a single one
> no encapsulation
> fucked up inheritance [I had no idea it was possible at all...]
> generics every-fucking-where
> I could go on...

this month the lead dev was not in and I had to make a new feature. Guess what I did :)

tdd [coverage >90%], a couple of builders, a factory or two, two composites, one decorator, only a few generics - only where really needed. Private fields, not a single @Autowired field [they were fucking my tdd], nicely abstracted integrations, and so on. Everything is writen according to clean code: max 10loc methods, <140col lines, reusable constants and utils, SOLID as a rock, etc.

Due date is next week. Took me 3 weeks to craft it.

Guess who's gonna be piiiiiiiiiiiiisssedd 😁

the best part - I don't even work there, our company was hired for xx hours as helping hands 😁

that's not all. They have like 6 envs and their deployment is all-fucking-manual. Will try to learn how to dockerize that app and deploy it on docker. Gosh I wish I could see his face when he's back 😁

p.S. From ethical point of view, he's the only dev who believes his code is perfect. No other dev in the team agrees. AND he once said: 'it's gonna be my way or no way at all'. So I don't think I did wrong... Did I? :)

For me, the worst co-worker is one who works by the principle of quantity over quality or a person who thinks quick and ugly fixes are a valid way to solve problems. Also: If there are unittest, don't fucking dare to change or remove them, just so your code runs without errors.

But in general, I just can't work with people who don't really think about what they are coding, people who just code straight ahead without making the simplest plan about how to solve something. Most of these people realize too late, that their approach was rather shitty, unreadable and unmaintainable.

I often see memes about "I forgot what I coded last [insert timespan here]". Though it is kind of normal, if it takes you too long to find out what you wrote, you should consider overthinking your coding approaches.

Just my 50 cents.

Damn I miss coding... 4 weeks of learning & exams is too long...

How to NOT write unit tests:

A colleague of mine has developed a new package of software, many of our new projects are going to use. So in his presentation of the new functionalities he also showed us that he used unit tests to cover some of his code. So i asked him to show me that all tests passes.

He: I can show you, but one test suit will fail currently.

Me: Why?? You told us, everything is finished and works fine.

He: That's right, but they will fail because I'm currently not in the customer VPN.

Me: Excuse me, WHAT??

He: Yes, I'm not in the VPN that connects me to this one customers facility in Hungary, where the counterpart of the software is runnung live.

Me: YOU WROTE UNIT TESTS THAT TEST AGAINST A RUNNING LIVE FACILITY??

He: Yes, so I can check, that the telegramms I send are right. If I get back the right acknowledgement, the telegramm structure is right and my code is working.

Me: You know, that is not the porpose of unit tests? You know, that these test should run in any environment?

He: But they are proving, that my code is working. Everytime I change something I connect to the customer and let the tests run.

Me: ...

Despite the help of some other developers we could not convince him that this was not good and he should remove them. So now this package is used in 2 new projects and this test suit is still failing, everytime you execute all unit tests.

Me When someone writes Unit test: Unit test is good, keep writing

Me when I have to write Unit test: FUCK OFFF

Real story:
Started fixing one file in one repo, build, doesn't build, go into other repo fix just one file there, but first I need to make myself a toolchain, making of toolchain fails because it depends on some dirty fix in the file I was fixing, refactor and clean that to a proper state, fuck yeah toolchain builds, source toolchain run make now, breaks with undefined reference, no time to debug plus fuck this automake, remove it, make a makefile, builds fuck yeah, shit now unittest are failing because why not, refactored that makefile as well, everything compiles, automate the test fully so that they are ran on the target out of make just because I'm a nice guy, fuck yeah everything works, commit this repo, commit other repo, review time, one of the guys gave up, the other one did it properly, found some shit there, fix that, done, merge, triggers CI fucking pass

All of this was done in 3h, Talk about efficiency

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...

Need to refactor the code base, and when looked at it, we don't have single UnitTest.... F*** them all

Spent 3 nights to make a single unittest pass. This night - sleep was soooo satisfying - i've finally felt I deserved to rest

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.

1. Run all the unittest and have a full green
2. Run a simulation
3. Run a simulation and all works properly
4. git push