Why test code?

Question

PHP

Here I write for example a simple code.
I need to implement the saving of news in the database.
I go to phpmyadmin, see the structure of the table.

yeah, we know the structure of the columns and their names.
I am preparing a presentation

, etc. ...
let it be so for the speed of understanding.
In the controller, we validate the data, if they come, then we call the model

public function insertPages(Array $array) {


        $params = [
            "title" => $array['title'],
            "url" => $array['url'],
            "content" => $array['content'],
            "keywords" => $array['keywords'],
            "description" => $array['description'],

        ];

        $sql = "INSERT INTO {$this->table} (`title`,`url`, `content`, `keywords`, `description`) VALUES (:title, :url, :content, :keywords, :description)";

        if( !parent::save( $params, $sql ) ) {

            throw new \Exception('Ошибка добавления статьи');

        }

    }

What is there to test and why? if it fails, we'll get an exception. We know the names of the columns. The data in the controller is validated.

Answer 1

What is there to test and why? if it fails, we'll get an exception. We know the names of the columns. The data in the controller is validated.

you must check the correct operation of the system. Just. And with an eye not only to the "now" (here we can quickly check with our hands), but also with an eye to the future. If you plan to throw out this code, there is no point in testing it. You will kill more time for testing automation than you will check by hand.
On the other hand, if this is just the tip of the iceberg, then it makes sense to write a simple autotest that checks the correctness of the work. So, if we make any changes, for example, we add comments, we will be 90% sure that nothing is broken. Why not 100%? because it is impossible to cover all test scenarios and it is not profitable. We usually check the most likely scenarios.
Further, everything depends on the complexity of testing. For good, our tests should be small and, most importantly, know nothing about implementation details. Let's say you want to check that the system is adding news correctly. The easiest way to check this is to create a news item and check that no errors are returned. To do this, you can make an HTTP request and get an HTTP response. The most simple.
But such a test works out for a relatively long time. Imagine that you are writing something more complicated. And you already have 100 different test scenarios for one piece of the system. As a result, this little piece will be tested for more than a minute, and we will have time to get bored. In order to simplify - we split this piece again and again until such pieces are found that we can check conveniently and quickly. For example, if the issue is the correctness of data validation, we can only test the controller, and if the issue is some separate business rules, we can take them out and test them separately. These will be integration tests.
Ultimately, we can break everything down to the level of separate small modules, essentially classes, and test them separately. This will be unit tests.
Well, again, crushing down should occur in order to simplify testing and development, and not just like that. Therefore, for example, no one covers the unit with tests for things that work, for example, with a database. Too expensive to support. In terms of tests, everything should be largely like a black box. You want something from the box and check if it does it. As soon as tests become tied to implementation, tests begin to bring pain.
In fact, this is the most difficult thing to test. Write testable and maintainable code, as well as stop yourself from testing "extra" parts of the system or going too deep into testing where it is not necessary.

Answer 2

What is there to test and why? if it fails, we'll get an exception. We know the names of the columns. The data in the controller is validated.

No one said that it is necessary to test right here.
In general, tests are needed so that when you develop your system, you can quickly check whether you broke something along the way in the old code.
If you have small software - you can not write tests.
If you have medium-sized software, you will easily break something without noticing it yourself.

Answer 3

Usually in tiny projects (up to 200tr) tests are superfluous: such projects are made and forgotten.
If the project is supported, then the tests are required. You must be sure that changing the code will not spoil the main functionality.
The easiest way to get started on the web is with functional tests.
I recommend either integrating phpunit into your framework, or selenium, etc.

Answer 4

Like what? Check if an exception is being thrown!

Answer 5

Don't test if you don't have to.

Answer 6

A separate question is whether you really need tests.
But if you really want to, then you can, for example, test that after calling insertPages you really have a page inserted.
To do this, mock the database, perform an insert, then get this record from the database, compare, checking whether what you wrote down and what was written matches.
What for? Well, for example, tomorrow some "Vasya" on the project will change the "content" field in the database to "content_id" and not normally refactor the code.
You can also check what will happen to invalid data, they should throw an exception, and so on.