|
2 | 2 |
|
3 | 3 | The following are best practices we as utPLSQL have learned about PL/SQL and Unit Testing. |
4 | 4 |
|
5 | | - |
6 | | -## Test Interaction |
7 | | - |
8 | | - - Tests should not depend on a specific order to run. |
9 | | - - Tests should not depend on other tests to execute. |
10 | | - - A developer should be able to run one or more tests of their choosing with out any prerequisites. |
| 5 | +## Test Isolation and Dependency |
| 6 | + |
| 7 | + - Tests should not depend on a specific order to run |
| 8 | + - Tests should not depend on other tests to execute |
| 9 | + - Tests should not depend on specific database state, they should setup the expected state before run |
| 10 | + - Tests should keep environment unchanged post execution |
| 11 | + |
| 12 | + |
| 13 | +## Writing tests |
| 14 | + |
| 15 | + - Tests should not mimic / duplicate the logic of tested code |
| 16 | + - Tests should contain zero logic (or as close to zero as possible) |
| 17 | + - The 3A rule: |
| 18 | + - Arrange (setup inputs/data/environment for the tested code) |
| 19 | + - Act (execute code under test) |
| 20 | + - Assert (validate the outcomes of the execution) |
| 21 | + - Each tested procedure/function/trigger (code block) should have more than one test |
| 22 | + - Each test should check only one behavior (one requirement) of the code block under test |
| 23 | + - Tests should be maintained as thoroughly as production code |
| 24 | + - Every test needs to be build so that it can fail, tests that do not fail when needed are useless |
| 25 | + |
| 26 | +## Gaining value from the tests |
| 27 | + |
| 28 | + - Tests are only valuable if they are executed frequently, ideally - with every change to the project code |
| 29 | + - Tests need to run very fast, the slower the tests - the longer you wait. Build tests with performance in mind (do you need to have 10k rows to run the tests?) |
| 30 | + - Tests, that are not executed frequently enough get rotten pretty fast and bring burden instead of value. Maintain tests as you maintain code. |
| 31 | + - Tests that are failing, need to be addressed immediately. How can you trust tour tests when 139 of 1000 tests are failing for a month? Will you be able to see each time that it is still the same 139 tests? |
11 | 32 |
|
12 | 33 | ## Tests are not for production |
13 | 34 |
|
14 | | - Tests generate will generate fake data, so it should go without saying. You should not deploy your tests to a production database. |
| 35 | + Tests generate will generate and operate on fake data. They might insert/update and delete data. You don't want tests to run on production database and touch on real-life data. |
15 | 36 |
|
16 | 37 | ## Tests and their relationship to code under test. |
17 | | - - Code that you want to test, and the tests should be in separate packages. |
18 | | - - Test code commonly will be the same schema as code |
19 | | - |
| 38 | + - Code under test and tests should be in separate packages. This is fundamental separation of responsibilities. |
| 39 | + - Test code commonly will be in the same schema as the tested code. This removes the need to manage privileges for the tests. |
20 | 40 |
|
21 | 41 | ## Version Control |
22 | 42 |
|
23 | | -Use a version control system for your code. Don't just trust the database for code storage. This includes both the code you have under test, and the unit tests you develop as well. |
24 | | - |
| 43 | +Use a version control system for your code. |
| 44 | +Don't just trust the database for code storage. |
| 45 | +This includes both the code under test, and the unit tests you develop as well. |
| 46 | +Treat database as target, destination for your code not as a source of it. |
0 commit comments