Seven months ago:
===============
Project Manager: - "Guys, we need to make this brand new ProjectX, here are the specs. What do you think?"

Bored Old Lead: - "I was going to resign this week but you've convinced me, this is a challenge, I never worked with this stack, I'm staying! I'll gladly play with this framework I never used before, it seems to work with this libA I can use here and this libB that I can use here! Such fun!"

Project Manager: - "Awesome! I'm counting on you!"

Six months ago:
====================
Cprn: - "So this part you asked me to implement is tons of work due to the way you're using libA. I really don't think we need it here. We could use a more common approach."

Bored Old Lead: - "No, I already rewrote parts of libB to work with libA, we're keeping it. Just do what's needed."

Cprn: - "Really? Oh, I see. It solves this one issue I'm having at least. Did you push the changes upstream?"

Bored Old Lead: - "No, nobody uses it like that, people don't need it."

Cprn: - "Wait... What? Then why did you even *think* about using those two libs together? It makes no sense."

Bored Old Lead: - "Come on, it's a challenge! Read it! Understand it! It'll make you a better coder!"

Four months ago:
==============
Cprn: - "That version of the framework you used is loosing support next month. We really should update."

Bored Old Lead: - "Yeah, we can't. I changed some core framework mechanics and the patches won't work with the new version. I'd have to rewrite these."

Cprn: - "Please do?"

Bored Old Lead: - "Nah, it's a waste of time! We're not updating!"

Three months ago:
===============
Bored Old Lead: - "The code you committed doesn't pass the tests."

Cprn: - "I just run it on my working copy and everything passes."

Bored Old Lead: - "Doesn't work on mine."

Cprn: - "Let me take a look... Ah! Here you go! You've misused these two options in the framework config for your dev environment."

Bored Old Lead: - "No, I had to hack them like that to work with libB."

Cprn: - "But the new framework version already brings everything we need from libB. We could just update and drop it."

Bored Old Lead: - "No! Can't update, remember?"

Last Friday:
=========
Bored Old Lead: - "You need to rewrite these tests. They work really slow. Two hours to pass all."

Cprn: - "What..? How come? I just run them on revision from this morning and all passed in a minute."

Bored Old Lead: - "Pull the changes and try again. I changed few input dataset objects and then copied results from error messages to assertions to make the tests pass and now it takes two hours. I've narrowed it to those weird tests here."

Cprn: - "Yeah, all of those use ORM. Maybe it's something with the model?"

Bored Old Lead: - "No, all is fine with the model. I was just there rewriting the way framework maps data types to accommodate for my new type that's really just an enum but I made it into a special custom object that needs special custom handling in the ORM. I haven't noticed any issues."

Cprn: - "What!? This makes *zero* sense! You're rewriting vendor code and expect everything to just work!? You're using libs that aren't designed to work together in production code because you wanted a challenge!?? And when everything blows up you're blaming my test code that you're feeding with incorrect dataset!??? See you on Monday, I'm going home! *door slam*"

Today:
=====
Project Manager: - "Cprn, Bored Old Lead left on Friday. He said he can't work with you. You're responsible for Project X now."

Every time whenever I see this message I imagine Travolta

Unit tests that do not test anything, even no assertions at all in some of them.

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

I feel like it might be a tiny bit (not much) better among React developers, but I ended up within one of those enterprise Angular till death companies, and it seems like nobody would ever doubt their Typescript skills, yet nobody actually understands Typescript at all.

In theory, I love Typescript. But you can abuse it to a point where it's almost as painful to work with as normal JavaScript.

It's not that I'm a master of Typescript.
But while I feel like I'm the only one understanding the mental model behind Typescript and also get stuff like mapped types or why you might wanna replace your enums with as const assertions, the rest calls themselves Typescript developers in their CV, no doubt. But It's way to easy to write whatever Typescript, while it's not as easy to reel get the hang of it.

Project with "unit tests" that does no assertions makes my eyes twitch

I'm starting to gain a dislike for OOP.

I think classes make it easy for me to think of the entities of a problem and translate them into code.

But when you to attempt to test classes, that's when shit hits the fan.

In my opinion, it is pointless to test classes. If you ever seen test code for a class, you'll notice that it's usually horrible and long.

The reason for this is that usually some methods depend on other methods to be called first.

This results in the usual monolithic test that calls every goddamn method on the class.

You might say "ok, break the test into smaller parts". Ok. But the result of that attempt is even worse, because you end up with several big tests cases and a lot of duplicate code, because of the dependency of some methods on others.

The real solution to this is to make the classes be just glue: they should delegate arguments onto functions that reside on its own file, and, maybe afterwards emit events if you are using events.

But they shouldn't have too much test code classes though. The test code for classes should be running a simple example flow, but never doing any assertions other than expecting no exceptions.

For the most part, you'd be relying on the unit testing that is done for each delegated function.

If you take any single function you'll see that it's extremely easy to write tests for it. In fact, you can have the test right next to the fuction, like <module>.xyz <module>.test.xyz

So I don't think classes shouldn't be used at all, they should just be glue.

As you do normal usage of this software this way, when a bug is discovered you'll notice that the fix and testing code for this bug is very usually applied to the delegated functions instead of being a problem of classes.

I think classes by themselves sound sane in paper, but in practice they turn into a huge fucking messes that become impossible to understand or test.

How can something like traditional classes not get chaotic when a single class can have x attributes and y methods. The complexity grows exponentially. And sometimes more attributes and methods are added.

Someone might say "well, it's just the nature of problems. Problems can have a lot of variables".

Yeah, but cramming all of that complexity into a single 200 lines class is insanity.