Just spend two fucking days debugging a few methods in our program. I used unit tests to call those methods (don't want to navigate through the complete program workflow)...
Yeah, guess what: the test cleanup includes a fucking rollback transaction function. So NONE NADA ZERO FUCKING CHANGES WILL BE PERSISTED. Fuck me

Well d'uhhh, unit tests should not persist any information.

Also, if a test actually interacts with another system, it's called an integration test.

Ah alright - never heard "Integration test". But that's good too know, thank you! :)

@DDerTyp think about unit tests as tests whether every individual piece of your puzzle is working as it should, as it's specified. It should test whether your logic in that particular method you have is correct. Whether it calls other methods when it should (without actually calling them).

In unit tests, failure of a component that's not subject to the test, should not influence the test results.

So unit tests look more like a "d'uhhhh" and are hard to justify, because you might as well just read the code. But the point in them is to code in the specs, so that someone else modifies the method and accidentally changes its logic beyond what it's supposed to do, the test would fail.

Unit tests should be done before build/deploy. Integration tests should be ran continuously to proactively fix any problems that occur in production environments. So if someone fucks up the network and your app can't connect to the DB, you'd immediately get an e-mail, before any customer tries to access it.