> And I can't even call any tests because I can't extend a non existant class, there's no objects in here!.

I'm gonna preach for the church of "away with unit tests": so what? You don't want to test code. Code is not what the user care about.

You want to test behavior. And for this you don't need to extend classes. You should not have to rewrite any code from your application. Like you say: write tests at the seam. Automate user inputs and checking outputs.

A good test suite should not need to be rewritten during refactoring. It should even allow you to change language or replace for an off-the-shelf solution you did not write. If a unit test suite does not allow that, unit tests are an impediment. And I don't care about the "test pyramid", like the IRL ones, it is just a relic; from an age when launching all your tests in parallel was unfathomable.

> You don't want to test code. You want to test behavior. A good test suite should not need to be rewritten during refactoring.

100% agreed.

> I'm gonna preach for the church of "away with unit tests"

I disagree with the semantics here.

From the article: "In short, your test is not unit if it doesn’t run fast or it talks to the Infrastructure (e.g. a database, the network"

This says _nothing_ about what part of the app structure you test. It's not always a class-method test. Outside-in, behaviour centric tests that are not close-coupled to structure, can also be unit tests. And most of the time, it's a better kind of unit test.

Kent Beck said many times: "tests should be coupled to the behavior of code and decoupled from the structure of code."

"test behavior" was the original intent of unit tests. The idea that unit tests are only close-coupled class-method tests, or that testing 2 collaborating classes from the same app at once counts as an "integration test" is a latter-day misconception. A dumbing down.