Last meeting I suggested we started using unit test and perhaps TDD on our platforms.

My boss is open to it and everyone seems to like the idea...

Now I just discovered that our dumbass coworker is trying to say by my back that its a bad idea to double the code efforts and that he sees no point in it...

Well dumbass cock sucker who can't even fucking remember how to write `docker-compose up` without messing things up you can fuck your self because you are certainly gonna be fucked sideways untill the end of the year.

Well, he has a point, at least for Backend code. You do double the code efforts, depending in how detailed your unit Tests are. Thats the reason i prefer a good set of Integration Tests over unit Tests (although they dont have to be mutually exclusive).

Integration Tests are waaay faster to write, and they check if your Backend actually works, instead oft checking if the code looks the way the devs want it to look.

@heikomat tests are not meant to check how the code looks, but rather how it behaves. When testing your APIs you are testing the full stack, which includes many possible bug sources. The holy grail is having unit-, integration-, system- and acceptance tests.

It sure costs some time to write the tests, but from my experience that time is later saved in faster code changes (because you are backed by tests) and waaaay smaller learning curve. I had projects where I spent weeks only trying to understand untested, undocumented code. Also your code becomes much easier and more elegant by making it testable alone.

@Huuugo everytime i had to deal with unit Tests it was because they needed to be adjustet, because the code changed. It was a huge overhead for little to no gain everytime anything in the code (or especially its structure) changed.

So far i'm missing the "this unit test was valuable to me just now"-moment. I always feel like I could have been more productive writing actual code.

Integration tests however are way faster to write, they only need to change when the api changes, instantly test if your non-breaking changes are actually non-breaking, and I feel that they give me more value for the time spent writing them. Sure, they can't always tell you where a bug exactly is, but at least that something is wrong, and finding that bug is usually not that hard.

@heikomat the deal here is that we have 0 automated tests... Anything would be better and he is talking shit about the "test idea" he doesn't have a clue about unit vs integration