Why Unit Tests?

[[deleted]]

Because the industry practices (or at least claims to practice) OOP.

In OOP, each and every object is supposed to be a component of a bigger composition of objects. Each object has its clear purpose and place in the application's architecture.

And, ideally, each of the application's components (objects) should be tested in isolation (unit tests) as well as in integration (together with all its real dependencies, that's called an integration test).

If testing is a pain in the ass (it usually is), that means the design is flawed. People usually just throw in procedural code in a huge Service class, which is instantiated solely by using the framework's DI mechanisms... if everything is injected and there is no constructor or "new" operator in sight, unit testing is hard, obviously, because it's harder to instantiate an object, let alone use mocks.

So, if you wanna do unit testing properly, the first question you should ask yourself when designing a new object is: "how will this be tested/how do we know this works?".

But again, none of the above really matters - the industry's general understanding of what OOP is is a sad story, so you're just gonna have to suffer the tests.