|
1 | 1 | import unittest |
2 | 2 | from testing import rle |
3 | 3 |
|
4 | | -__doc__ = """Testing in Python is not a part of language, but it is a part of standard library. |
5 | | -There are no strict guidelines on how to write tests, but there are some best practices. |
6 | | -Some of them are: |
7 | | -* Tests should be isolated from each other |
8 | | -* Test user-visible behavior first |
9 | | -* The best test is integration test without many dependencies |
10 | | -* Integration tests are more effective because they take less changes to break |
11 | | -* Data-driven tests are better than copy-pasted tests |
12 | | -* Less code, more data |
13 | | -* Asynchronous code is very hard to test. Resort to making load/integration tests instead |
14 | | -
|
15 | | -Let's test some approaches to testing in Python: |
16 | | -Print |
17 | | -Better than nothing, but not good |
18 | | -
|
19 | | -Assert |
20 | | -* Better than nothing, better than print |
21 | | -* Fits for small scripts |
22 | | -* Do not use in production |
23 | | -
|
24 | | -Assert with context |
25 | | -* Assert context is additional information about the error |
26 | | -* You can pass not only strings, but also any object |
27 | | -* It's convenient to use the tuple |
28 | | -
|
29 | | -Doctest is a module for testing docstrings |
30 | | -* It works by running the code in docstring and comparing the result with the expected one |
31 | | -* Problem of doctest is that it's hard to test multiline code |
32 | | -* It general lots of false positives |
33 | | -* Testing code with documentation is not a good practice, because documentation tends to become outdated |
34 | | -* From the other side, it's a good reminder to update documentation |
35 | | -* It can be considered as a tool for testing documentation, not code |
36 | | -
|
| 4 | +__doc__ = """ |
37 | 5 | Python.unittest |
38 | 6 | * Simple unit testing library |
39 | 7 | * API reminds of Java's JUnit |
|
50 | 18 | * It can be used for creating temporary files, databases, etc. |
51 | 19 | * Problem with setUp/tearDown is bad composition, that is different tests can affect each other, |
52 | 20 | they may require different setUp/tearDown, etc. |
53 | | -
|
54 | | -PyTest |
55 | | -* Simple unit testing framework |
56 | | -* Runs all tests in the current directory and subdirectories: |
57 | | - python3 -m pytest 01-testing.py |
58 | | -* Instead of family of methods assert*, it uses simple assert |
59 | | -* It has a lot of plugins, for example, pytest-asyncio |
60 | | -* It works by parsing the code, building the AST and running the tests |
61 | 21 | """ |
62 | 22 |
|
63 | 23 |
|
|
0 commit comments