Python: Automated testing
2026-02-21 02:59 Diff
https://hexlet.io/courses/python-testing/lessons/bad-practice/theory_unit

Like any other code, you can write tests in many ways, including terrible ones. In addition to some general coding practices and standards, tests have their peculiarities that you need to know about. In this lesson, we'll go over some of them.

Tests affecting each other

One of the most important rules is that tests should not interfere with each other. It means each test should run as if no other test existed. It's easy to break this rule. One test may create a file, change a variable, or write something to the database.

If any of the other tests stumble upon these changes, they may not work:

  • Fail where they shouldn't
  • Pass where they shouldn't

In addition, this situation also means uncertainty. Such tests may crash for no apparent reason. For example, when the test runs in isolation, it works, but when the other tests run in parallel, it crashes:

This situation is common in tests that actively interact with the external environment, such as a database or file system. Testing side effects has its tricks, which we'll look at in the advanced testing course.

Conditional constructions in tests

Let us observe the code:

Any branching in tests is multiple tests in one. Branching generates code that we need to test itself. It happens because we no longer know the order of execution and can accidentally violate it. It's better to create independent tests for each branch.

Tests outside of tests

Fixtures prepare data and environment for testing. Test functions perform checks and invoke code for testing. But sometimes developers overdo it:

The tested code is called in the result() function. This approach complicates test analysis because it turns everything upside down.

Tests with too much detail

Some programmers try to spread their code across files, modules, and functions as much as possible. The same can happen with tests. Instead of creating one test with five checks, they make five tests with one check:

This separation has one consequence: there's more code, which means it's harder to refactor in the future.

Code with tests versus without tests

This crucial question helps to understand how good a programmer is at writing tests.

Some types of tests are complicated and require extra time. But at the same time, everyday tests written along with the code should lead to faster development. There are good reasons for this:

  • Tests help to identify unsuccessful solutions earlier and thus influence the design of the code
  • Tests simplify the preparation of input data; you only need to prepare it once
  • Tests help to verify your code because they check everything, including borderline cases
  • Tests make refactoring easier and faster because you don't have to check parts of the code manually
  • Tests improve the team atmosphere by reducing stress levels