At what point is it better to write tests? In general, there are three approaches:
- Write tests after your code
- Write tests while you're writing your code
- Write tests before you write code
In this lesson, we'll figure out the features of each approach.
Testing after code
In some situations, there isn't much choice. For example, in system testing, tests should simulate user behavior and perform actions in the browser. We write these tests after the code. The programmer can choose from the options above in integration, unit, and other low-level tests.
Testing before code
The tests-after-code approach is one of the less useful ones. Let's figure out why this is so. The very process of writing code involves constantly running the code and checking that it works. In the simplest tasks, the program can run quite quickly:
# Its is easy to run and to check results
capitalize('hello') # Hello
Preparing data to check the code can take dozens of minutes in real-life code. Moreover, the results produced after testing the code may be quite complex, for example, many records in a database or a complex structure.
The code test runs turn into a whole adventure:
# It is difficult to prepare data and check the result of the work
# Loading goods from 1C into the database
load_goods_from_1c()
It is where writing tests before code comes into play. For many novice developers, this phrase causes a bit of a stupor. How can we write tests before the code? It turns out you can.
Suppose we want to write a function that repeats a string passed to it a specified number of times:
repeat('$', 3) # $$$
We know two important things:
- What is a pure function
- What does this function take as input
Knowing this means we can already write tests:
def test_repeat():
assert repeat('$', 3) == '$$$'
An experienced developer can write this code in 15–20 seconds. But to check that this code runs, we need to type poetry run pytest
in the console.
Testing before writing code has another advantage — it forces the programmer to think not about the code but about the design of their solution. It pushes the programmer to think about how people will use their application. It is a way to create competent interfaces and is often the key to success.
Testing during code
In the development world, there is an approach in which we write tests before the code. It's called Test-Driven Development:
According to the inventors, development through testing implies that the entire development process consists of a repeating cycle:
- Programmers write a test for each iteration
- They see that the test doesn't pass
- They add code that satisfies this test
Rinse and repeat. As a result, we build the application step by step.
Thanks to it gaining traction, everyone is talking about this method. In it, we write tests for all parts of the code with maximum detail. This kind of TDD aims towards the importance of design but focuses on specific functions and classes in the application instead of the whole picture.
But there is another approach to TDD, where developers rarely write tests for internal parts. You can read more about this in the article in the additional materials.
Are there any more questions? Ask them in the Discussion section.
The Hexlet support team or other students will answer you.
For full access to the course you need a professional subscription.
A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.