Is a thorough check of all code the key to bezbugnosti, and what to do if it is in our team?

Question

Software testing

Epigraph. Literally an hour ago, I wrote a code of 70 lines, in which I found 3 bugs at the first recheck, 1 more at the second, and 1 more at the third. And this is constant.
Previously, we had releases teeming with bugs in general.
Now I personally took up this (it's okay that I'm just a middle), I began to look for bugs in myself and my colleagues. Check every line, and not just once. Fortunately, I have something like autism, a tendency to check everything and generally do routine. So I find a lot of bugs.
Auto-tests, if anything, are written. But, of course, some bugs are in what seems to be already covered by tests.
1. So, do you think there will really be no bugs in the release?
2. Maybe not write auto-tests at all? Indeed, in terms of labor intensity, it is easier to look at something in the code than to write a test for this case. Or write them only for the complex, that is, do not make them unit tests, strictly speaking.

Answer 1

Both. And manual verification of the code (not your own, but your colleagues), and tests.
But this is ideal, but in reality everything is limited by staffing and deadlines for completing tasks, and sometimes there is no time to carefully catch bugs.

Answer 2

1. bugs are everywhere
2. you don't understand the logic of the tests.
Tests are not mind-blowing; their purpose is to check work, that is, write them first, you get red badges. You add code, the tests turn green. Moreover, you always have this code, it is automatically executed, does not suffer from inattention and gives a clear indication of the problem here.
As for the complexity, with each new release, you check all the features + new features + their interaction with the previous code. Extra work and repetitive. Tests do it for you.

Answer 3

Epigraph. Literally an hour ago, I wrote a code of 70 lines, in which I found 3 bugs during the first recheck, 1 more at the second, and 1 more at the third.

How are lines counted? If this is 70 lines of one procedure with cycles, then this is a problem.
In addition to the fact that "tests are written", it is important how they are written. I even saw footcloths for dozens of lines that were called "unit tests".
The described bug tests should catch. In well-tested code, they should check all branches (conditions) in the method, and return values, incl. border conditions.
And also stat. analysis, immutability.
Don't make the release a big event, release often (1 or more times a day) and little by little, recruit responsible developers.
The idea that tests are expensive and don't pay off is a very common sign that tests or code are poorly written. Writing a test is not much longer than running the code itself, only after writing the tests you can run them automatically, and not start the whole system again. Yes, and the idea of ​​\u200b\u200bfrequent deployment is killing it.
In general, watch this report - https://www.youtube.com/watch?v=VDfX44fZoMc .
And yes, to reduce the cost of covering the code with unit tests, you need to reduce the coherence in the code, otherwise you will drown in mocks.
Design improvement is one of the main goals of unit tests (and the main goal when using tdd).

Answer 4

2. Maybe not write auto-tests at all? Indeed, in terms of labor intensity, it is easier to look at something in the code than to write a test for this case. Or write them only for the complex, that is, do not make them unit tests, strictly speaking.

Autotests are not written to check something in your line, but to check it every time you change the code. Therefore, writing unit tests, auto-tests should be done in such a way that they check the logic of work, and not every line.
During subsequent work (new versions, fixing any bugs), autotests will confirm that the already working functionality is at least not broken by new changes.
Therefore autotests - it is necessary to write.
A programmer and a tester (especially an automation test engineer) are also somewhat different people, each with their own specialization and professional knowledge, because not everything can fit into unit tests, especially in complex multi-component products.