illustration for the TESTING article

 

Testing is definitely useful. It's always nice to have unit, integration, and end-to-end tests available. However, in practice, there are almost always trade-offs to be made between writing code and writing tests, and it is quite obvious that the priority shifts towards writing code.

The intensification of development results in a shortage of tests, and in general, this situation seems justified. Numerous code refactorings, and sometimes changes in business logic, can be quite an argument for postponing testing until the moment when the main processes in the code have acquired stable outlines.

How, then, can you improve the efficiency of writing tests? We propose an approach in which the core processes are tested first. Moreover, such a process is tested entirely, passing through different parts of the code, and sometimes system components. pytest test framework allows you to parameterize the input data of a process and check the output result using a minimum of code. One advantage of this approach is that if some parts of the main process change, minimal changes to the tests will be required. In addition, you can often encounter a situation where a function is called a few times in the code, and the format of the input data of such functions is clearly known. For example, the logic is encapsulated in some kind of function, the function is part of a more global process and is called only in it. Testing such functions separately does not add efficiency compared to testing the main process to which the function belongs.

In general, such a methodology can be briefly formulated as:

  1. We cover the entire main working processes with tests (i.e. the process itself acts as a testing module, sometimes intercomponent)
  2. if resources are available, we focus on coverage and supplement the rest of the code with unit tests

By the way, in ecosystem54, to automatically create documentation, we use an approach based primarily on the entire core processes (flow). The main process (flow) is indicated in the description of functions and methods. The assembler then goes through the descriptions and builds a flowchart of the entire process.

 

 

Also read: