How to start writing tests?

Question

Python

Actually, there was such a question.
The "pick and go" approach doesn't work. It is not clear what to test, what not, which cases are always useful to remember, etc.
But I understand that the ability to write tests will be very useful to me in the future (at the moment I am finishing the 11th grade and I plan to enter a university with an IT specialty).
Thanks in advance for any advice!
PS Most of the time I program in Perl and Python. If you have advice specifically on these languages, I will be doubly grateful.

Answer 1

When you don’t know at what moment to write tests, get into a simple habit: if you find a bug, before you close it, cover it with a test that catches it. With such an approach with a dynamic language, you will not notice how the entire project will be overgrown with tests. And then when you understand the profits, a habit and inclination to TDD may well form.

Answer 2

Tests are needed primarily in those places that can break. These are, as a rule, difficult-dependent places. Start writing tests at the highest level, for example, on api models and http routings (if it is a web), gradually going down to reasonable limits. In general, in true Zen-TDD, tests began to be written, and then the functionality for them.

Answer 3

Tests should be written for components that are more likely to break easily (and cause you to spend time looking for the problem). If you have code that retrieves a table from the database or adds a user, or a typical controller, or a typical model, there is no point in testing it.
But if, for example, you have a HumanDateParser class that recognizes dates in text and returns them as a timestamp, you should make a test for it. The simplest test will be a dictionary, a string type - the expected answer, for example (sorry, I don’t know Python, I write in javascript):
var answers = {
"May 14, 2002": '2002-14-05',
"April 4": '$currentYear -04-04',
"March 114": false,
"tururu": false
};
After that, the simplest loop sorts through the values ​​from the dictionary, feeds them to HumanDateParser and compares the answers, if something is wrong, it blows an error. If you later find a bug in this module, you will add the lines that caused the bug to the answers.
Also, you will need to somehow automate testing, for example, so that testing scripts run on schedule, or after a commit and when bugs are found, they send letters to whoever needs it.
And to do tests for the sake of tests and 100% coverage, in my opinion, is stupid. Do not forget, for example, that in case of any changes in the covered code, you will most likely have to redo the tests as well.

Answer 4

Read books about TDD. This
helped me a lot at the time.

Answer 5

The following approach helped me on existing code:
- functional / acceptance tests for new or changed features (in fact, a description of the technical specification on some DSL)
- modular / integration when refactoring
- tests for bugs
And it is not necessary in most cases, IMHO, to test the internal state of even the system as a whole, even its individual objects or variables. Its behavior needs to be tested. Compliance of the result with the expected. At the same time, it is necessary to focus on semantics, and not on knowledge of the internals, not to violate encapsulation. With this approach, it will not be necessary to write, for example, tests for getters and setters separately, it is enough to write one test that the value returned by the getter is equal to the value set earlier by the setter. Or, moving to the system as a whole, you do not need to test that pressing the "save" button by the user causes some changes in the database. You need to test that after clicking this button, the user can get this data.