Unit testing won’t make your code 100% bug free
Unit testing focusses on separate units and not your complete serverpark. It wont fix bug introduced by other libraries. It won’t fix storage and memory issues. Unit is just a way of working if implemented correctly will reduce amount of bugs.
Bad unit tests can be just as bad as no unit tests
Bad unit tests can give a development team a false sense of security. Bad unit tests ignore the complete functionality of the code it should be testing. For example if a method returns a boolean value only the true results are tested. Another example of a bad unit test when a secondary outcome is ignored like broadcasting a event on an eventbus.
100% code coverage doesn’t mean a testing job well done
It’s possible to force teams to get 100% code coverage, sadly this could force developers to game the system. For example you can wrap all your tests and assertions in a try catch block. You’ll get 100% code coverage but the tests are useless. Sadly i didn’t make this story up, it’s a real world example.
Writing tests takes to much time
Initially writing tests take a lot of time. Unit testing is a skill which developers need to learn. Some stories make 3 times as much time when writing unit tests for them. But in the end (if done correctly) it results in solid tested code which is harder to break. Also a neat side effect is that when writing code with unit tests in the back of your mind results in more neat code.
Unit tests don’t need maintenance
Every change you make in your code does have a high change to impact your unit tests. Adding method, public variables or new side effects all results in new tests. That’s why unit tests require a lot of updating or even completely rewriting unittests.
