Unforeseen bugs and functional gatherings constantly appear, how to deal with it?

Question

PHP

Good afternoon. At our company, on projects, there is always some kind of crap with the functionality. What I mean.
For example, the customer wanted to add some new parameter to the product. And this parameter should now be taken into account in many places on the site, in filters, when displayed in lists, on a card, for example, in the basket, in the admin panel, etc.
In general, the problem is that when you add some new functionality (or less often change an existing one), some part of the site crashes, it’s not that the site doesn’t work right, but it just works crookedly, for example, it began to be displayed crookedly or some information does not show up at all, some conditions stop working, etc.
That is, this happens precisely because the functionality is growing, and remembering where, what should change when adding or removing something else is simply not possible ... And this garbage happens all the time, and what we have and a tester (in terms of UI), but he is also able to miss a moment ...
I know now they often began to use unit tests, autotests, but how justified are they? That is, if they begin to implement, then all these problems listed above will disappear? It is very interesting to know how this happens in other companies, projects?

Answer 1

1. Perhaps you have some sort of curved overall architecture.
Read about SOLID.
2. In general - if you make changes to a function - a simple file search in a text editor will tell you where the function is used.
3. Complex business logic other than "received a request, went to the database, gave the data in a beautiful wrapper" must be documented in the wiki + in the code.
The question "the parameter should be taken into account in many places, we don't remember where" is a question of a well-written technical specification, by the way. It is assumed that the TOR is written by a person who has a general understanding of the project.
4. In my opinion, it is unit tests that are needed in 1% of cases. Using mocks is of no real use on a live project because the cause of the crash could be anywhere.
5. We use codeception.com Acceptance testing in combination with a certain database dump that is loaded before the tests.
All migrations are rolled onto the database dump (we use phinx.org ) and then everything is checked, up to the output of specific content values.
I honestly warn that the time to develop tests exceeds the time to implement the functionality by about 1.5-2 times.

Answer 2

functional and unit tests - solve the above problems and get rid of the regression of the code and application behavior.

Answer 3

>> That is, if you start to implement them, then all these problems listed above will disappear-honestly, these problems will not disappear, but will remain. Another thing is that you will be able to see the regression in time and fix it even before the product reaches the customer (ideally, before it gets to the QA department =) )
>> I know now unit tests and autotests are often used, but how justified are they? - justified. and how. Unit tests are justified for programmers to make sure that what they have written (classes, methods, etc., etc.) does not fall off after introducing something new, or refactoring. The next level is "autotests", a completely different level of automation that affects several modules at the same time, which also allows you to find problems, regressions in time and solve them accordingly.

Answer 4

Tests really help. You need to know what to test.
1) complex logic (preferably unit tests).
2) workflows -- high-level tests, such as acceptance tests.
I don't like moki, but sometimes you can't do without them.