What is the essence of autotests with PHPUnit on the form example?

Question

Unit testing

Good day.
I recently took up the study of unit testing, and for some reason I just can’t understand what the point is. For a long time I googled, read, everywhere some primitive examples, of which it is generally not clear how to apply it in practice, I did not find examples "from life" anywhere.
Let's take the simplest example: we have a form for commenting on the site. Let's say we forgot to do escaping, and now if there is a single quote in the comment text, the SQL query breaks and gives an error + we get an injection vulnerability.
We have a testing class with a method for checking the success of inserting a record into the database. We write the text of the comment without single quotes in the testing method - everything works, the test is successful. Those. to see an error, you need to pass many different data sets to the testing method, and it is far from certain that we will be able to "predict" all possible options that "break the system", otherwise we would just do certain checks at the code level. In this case, this is a screen version, so it makes no sense to write a test with a single quote in the comment text, because we already know that escaping will be done and there will be no error.
I don't seem to understand the concept itself. Explain, please.
PS And if possible, an example from practice.

Answer 1

it no longer makes sense to write a test with a single quote in the comment text, because we already know that escaping will be done and there will be no error.

Tests are often written before code and are a great opportunity to think about edge cases ahead of time. When you write code, you think about the "successful" execution branch - how to make the functionality work. When you write tests, you are on the contrary going down the "pessimistic" branch - what can go wrong at runtime? In the first case, it is easy to forget something, because the head is already occupied with implementation details.
In addition, if you write tests first and then code, the architecture will improve (in theory, of course). It is very, very painful to cover code with a curved architecture with tests, so out of sheer laziness you will try to follow all sorts of SOLIDs, KISSs, YAGNIs and other acronyms.
In addition, the code is constantly changing, and in the process of refactoring it is quite possible for you to break the escaping and find out about it when your entire base is taken away through injection.
This is about testing in general. Specifically, the example from the question makes no sense, because a) there is no point in writing your own layer of work with the database when there are many ready-made convenient and tested tools, and b) what you described is not a unit test (well, or at least a few unit tests ).