0 added
0 removed
Original
2026-01-01
Modified
2026-02-21
1
<p>The information we've looked at is already enough for everyday testing. Before we dive into more complex topics and features of Pytest, let's go through the testing path of the library. We'll talk about organizing tests and good and bad practices. It will help you get the right attitude towards testing in general.</p>
1
<p>The information we've looked at is already enough for everyday testing. Before we dive into more complex topics and features of Pytest, let's go through the testing path of the library. We'll talk about organizing tests and good and bad practices. It will help you get the right attitude towards testing in general.</p>
2
<h2>What is unit testing</h2>
2
<h2>What is unit testing</h2>
3
<p>In this lesson, we'll analyze the basics of unit testing**. This type of testing examines program modules in isolation from all other parts. They test basic language constructs such as functions, modules, and classes. These tests don't guarantee that the entire application will work, but they help when a program module has complex logic.</p>
3
<p>In this lesson, we'll analyze the basics of unit testing**. This type of testing examines program modules in isolation from all other parts. They test basic language constructs such as functions, modules, and classes. These tests don't guarantee that the entire application will work, but they help when a program module has complex logic.</p>
4
<p>Let's try to test a<a>stack</a>. You'll no doubt remember that a stack is a list of items organized by LIFO (Last In First Out). Typically, stacks themselves are often used to implement algorithms. Developers often use them in low-level code, such as within programming languages or operating systems:</p>
4
<p>Let's try to test a<a>stack</a>. You'll no doubt remember that a stack is a list of items organized by LIFO (Last In First Out). Typically, stacks themselves are often used to implement algorithms. Developers often use them in low-level code, such as within programming languages or operating systems:</p>
5
<h2>Testing basic features</h2>
5
<h2>Testing basic features</h2>
6
<p>Let's write our first test. The first test should always check a positive scenario, one that involves the main functionality of the component:</p>
6
<p>Let's write our first test. The first test should always check a positive scenario, one that involves the main functionality of the component:</p>
7
<p>This test checks whether the two main methods work, excluding borderline cases. The test runs two statements that examine the values extracted from the stack. On the Internet, you may read opinions saying that multiple checks within a test are wrong.</p>
7
<p>This test checks whether the two main methods work, excluding borderline cases. The test runs two statements that examine the values extracted from the stack. On the Internet, you may read opinions saying that multiple checks within a test are wrong.</p>
8
<p>Many people believe that tests must be as detailed as possible and that you must create a new test for each check:</p>
8
<p>Many people believe that tests must be as detailed as possible and that you must create a new test for each check:</p>
9
<p>It's worthwhile to highlight other scenarios in a separate test that require different data or perform a different sequence of actions. But this approach doesn't always work. It often leads to code bloat and duplication for no apparent benefit.</p>
9
<p>It's worthwhile to highlight other scenarios in a separate test that require different data or perform a different sequence of actions. But this approach doesn't always work. It often leads to code bloat and duplication for no apparent benefit.</p>
10
<h2>Testing additional features</h2>
10
<h2>Testing additional features</h2>
11
<p>The next test is a test for additional stack functions. It includes a check to see if the stack is empty:</p>
11
<p>The next test is a test for additional stack functions. It includes a check to see if the stack is empty:</p>
12
<p>This test covers three situations at once:</p>
12
<p>This test covers three situations at once:</p>
13
<ul><li>The initial state of the stack</li>
13
<ul><li>The initial state of the stack</li>
14
<li>The state of the stack after adding elements</li>
14
<li>The state of the stack after adding elements</li>
15
<li>The state of the stack after removing all elements</li>
15
<li>The state of the stack after removing all elements</li>
16
</ul><p>In principle, this is sufficient. However, there may be situations where the `not' check fails. Do you have to try to find all the options? No. Every line of code in the project is a potential place to change in case of edits. If there's any doubt about whether a check is needed, it's better not to write it. That means you'll find the minimum that's worth it. Rare situations require test coverage only if they are critical to performance.</p>
16
</ul><p>In principle, this is sufficient. However, there may be situations where the `not' check fails. Do you have to try to find all the options? No. Every line of code in the project is a potential place to change in case of edits. If there's any doubt about whether a check is needed, it's better not to write it. That means you'll find the minimum that's worth it. Rare situations require test coverage only if they are critical to performance.</p>
17
<h2>Borderline cases</h2>
17
<h2>Borderline cases</h2>
18
<p>The last thing we can test is the behavior of the pop() function when there are no elements on the stack.</p>
18
<p>The last thing we can test is the behavior of the pop() function when there are no elements on the stack.</p>
19
<p>By design, the stack throws an exception if we attempt to pop elements from it when it is empty. In other words, this situation is considered an error; the programmer should always make sure that the stack isn't empty:</p>
19
<p>By design, the stack throws an exception if we attempt to pop elements from it when it is empty. In other words, this situation is considered an error; the programmer should always make sure that the stack isn't empty:</p>
20
<p>Borderline cases aren't always so easy to see. It is unlikely that any programmer can write all the necessary tests at once.</p>
20
<p>Borderline cases aren't always so easy to see. It is unlikely that any programmer can write all the necessary tests at once.</p>
21
<p>Imagine an error occurred in code that didn't have a test. In that case, write a test that reproduces that bug and then fix it. It is the only way to maintain a sufficient level of reliability without turning development into continuous bug fixing.</p>
21
<p>Imagine an error occurred in code that didn't have a test. In that case, write a test that reproduces that bug and then fix it. It is the only way to maintain a sufficient level of reliability without turning development into continuous bug fixing.</p>