You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Don't repeat yourself. Use already implemented code such as:
6
-
-`load_repo_main_dotenv.bash`
7
-
-`import_dna_lib.bash`
8
-
-`load_super_project_config.bash`
9
-
-_N2ST_ library
10
-
-_NBS_ library
11
-
- Path management:
12
-
- Case 1 › system wide:
13
-
- via symlink `/usr/local/bin/dna` → `/path/to/dockerized-norlab-project/src/bin/dna`;
14
-
- via `~/.bashrc` ← `PATH=${PATH}:${DNA_PATH}:${NBS_PATH}:${N2ST_PATH}`.
15
-
- Case 2 › manual load:
16
-
- each super project can optionally use the env var `DNA_PATH`, `NBS_PATH` and `N2ST_PATH` define in `.env.dockerized-norlab-project`.
17
-
2
+
18
3
## Repository Organization
19
4
-`src/bin/dna` is the DNA application entrypoint
20
5
-`src/lib/` contain library files
@@ -25,49 +10,83 @@
25
10
-`utilities/tmp/dockerized-norlab-project-mock` is use for cloning a fresh copy of a mock "super project" from https://github.com/norlab-ulaval/dockerized-norlab-project-mock.git on test execution.
26
11
`dockerized-norlab-project-mock` is a mock of how a user would install and uses DNA. We refer to this as a "super project" or the "user side".
27
12
28
-
## Version Control
29
-
- Never `git add` or `git commit` changes, all changes require explicit code review and acceptance by the codeowner.
13
+
## General Instructions:
30
14
31
-
## Tests Requirements
32
-
- In the context of testing:
33
-
- the definition of _pass_ is that a test exit whitout error. Synomym: _green_, _successfull_;
34
-
- the definition fo _done_ mean that all tests where executed and all tests passed.
15
+
### Planning instructions
16
+
- Always put plan ready for review in the `.junie/plans` directory.
17
+
18
+
### Coding instructions
19
+
- Don't repeat yourself:
20
+
- Use already implemented code such as:
21
+
-`load_repo_main_dotenv.bash`
22
+
-`import_dna_lib.bash`
23
+
-`load_super_project_config.bash`
24
+
- Leverage functionality provided by submodule such as _N2ST_ and _NBS_ library whenever possible.
25
+
- Path management:
26
+
- Case 1 › system wide:
27
+
- via symlink `/usr/local/bin/dna` → `/path/to/dockerized-norlab-project/src/bin/dna`;
28
+
- via `~/.bashrc` ← `PATH=${PATH}:${DNA_PATH}:${NBS_PATH}:${N2ST_PATH}`.
29
+
- Case 2 › manual load:
30
+
- each super project can optionally use the env var `DNA_PATH`, `DNA_ROOT`, `NBS_PATH`, `N2ST_PATH` and others define in `.env.dockerized-norlab-project`.
31
+
32
+
### Version Control Instructions
33
+
- Never `git add` or `git commit` changes, all changes require explicit code review and acceptance by the code owner.
35
34
36
-
### Testing Strategy
35
+
## Testing Strategy Instructions
36
+
- In the context of testing:
37
+
- the definition of _pass_ is that a test exit without error. Synonym: _green_, _successful_;
38
+
- the definition fo _done_ mean that all tests where executed and all required tests passed, i.e. tests are _green_.
37
39
- Inspect the tested script/functions for business logic related error or implementation error. Propose correction before going forward if any.
38
-
- Write tests who chalenge the intended functionality or behavior.
- All new scripts or functionalities need to have (either or both):
41
-
-**Unit-tests**:
42
-
- Those are tests that check if the core expected behaviors are satisfy. It test a piece of code in a stand alone fashion.
43
-
- Use [N2ST](https://github.com/norlab-ulaval/norlab-shell-script-tools) bats tests tools for unit-test (See `tests/run_bats_core_test_in_n2st.bash` script) and a corresponding bats unit-test `.bats` file in the `tests/tests_bats/` directory. N2ST Bats tests are running in a docker container in complete isolation with a copy of the source code.
44
-
-**Integration tests**:
45
-
- Those are test case where there is multiple script interacting whith each other or we want to assess execution from begining to end;
46
-
- Those tests are devided in two categories:
47
-
- Dryrun: either make use of a `--dry-run` flag implemented in the script or make use of the docker `--dry-run` flag;
48
-
- Test: all other integration test case that are not dryrun.
49
-
- Use [NBS](https://github.com/norlab-ulaval/norlab-build-system) tests tools for integration-test (See `tests/run_all_dryrun_and_tests_script.bash` script) and a corresponding `test_*` or `dryrun_*` script in the `tests/tests_dryrun_and_tests_scripts/` directory.
50
-
- New integration test script must go in the `tests/tests_dryrun_and_tests_scripts/` directory.
51
-
- Their should be at least one test file (`.bats` and/or `.bash`) per coresponding source code script.
52
40
- Identify relevant test cases e.g., behavior validation, error handling, desired user feedback, ...
41
+
- If the tested script implements helper functions (i.e., support function meant to be used by the main function), test those functions first.
42
+
- Always execute all unit-tests and all integration tests before submitting and only submit when _done_.
43
+
44
+
## General Testing Instructions
45
+
- Write tests who challenge the intended functionality or behavior.
53
46
- Divide test file by test cases: one test function per test case.
54
-
- If the tested script implement helper functions (i.e., support function meant to be used by the main function), test those functions first.
55
47
- Provide a summary explanation of the test case:
56
48
- What does it test for;
57
49
- What's the test expected outcome (i.e, should it pass or fail);
58
50
- If you do mock something, justify why.
59
-
- All tests in the `tests/` directory must pass.
60
-
- Always execute all unit-tests and all integration tests before submiting.
51
+
- Their should be at least one test file per corresponding source code file.
- All new scripts or functionalities need to have (either or both):
54
+
-**Unit-tests**:
55
+
- Those are tests that check if the core expected behaviors are satisfy. It test a piece of code in a stand alone fashion.
56
+
-**Integration tests**:
57
+
- Those are test case where there is multiple script interacting whith each other or we want to assess execution from beginning to end;
61
58
59
+
### General Mocking Instructions
60
+
- Never mock the logic that is actually tested.
61
+
- Copying the source code in a test instead of using the real one fall into the mocking category, don't do that.
62
+
63
+
### General Instructions On Tests Execution
64
+
- Always run unit-tests before integration tests.
65
+
- Never run integration tests if any unit-tests fail.
62
66
63
-
### Instruction On Mocking
67
+
## Shell Script specific Testing Instructions
68
+
All instructions in sections _General Testing Instructions_ plus the following:
69
+
- All new scripts or functionalities need to have (either or both):
70
+
-**Unit-tests**:
71
+
- Use [N2ST](https://github.com/norlab-ulaval/norlab-shell-script-tools) bats tests tools for unit-test (See `tests/run_bats_core_test_in_n2st.bash` script) and a corresponding bats unit-test `.bats` file in the `tests/tests_bats/` directory. N2ST Bats tests are running in a docker container in complete isolation with a copy of the source code.
72
+
-**Integration tests**:
73
+
- Those tests are divided in two categories:
74
+
- Dryrun: either make use of a `--dry-run` flag implemented in the script when available or make use of the docker `--dry-run` flag;
75
+
- Test: all other integration test case that are not dryrun.
76
+
- Use [NBS](https://github.com/norlab-ulaval/norlab-build-system) tests tools for integration-test (See `tests/run_all_dryrun_and_tests_script.bash` script) and a corresponding `test_*` or `dryrun_*` script in the `tests/tests_dryrun_and_tests_scripts/` directory.
77
+
- New integration test script must go in the `tests/tests_dryrun_and_tests_scripts/` directory.
78
+
- Their should be at least one test file (`.bats` and/or `.bash`) per corresponding source code file.
79
+
80
+
81
+
### Shell Script specific Mocking Instructions
82
+
All instructions in sections _General Mocking Instruction_ plus the following:
64
83
- You can mock shell core command an docker command.
65
84
- You can mock `docker [OPTIONS|COMMAND]` commands and `git [OPTIONS|COMMAND]` commands.
66
-
- Don't mock the functions that are tested in the tested script.
67
85
- Avoid mocking N2ST functions, at the exception of those in `${N2ST_PATH}/src/function_library/prompt_utilities.bash`. For example, instead of re-implementing `n2st::seek_and_modify_string_in_file`, just load the real one and test that the content of the file at `file_path` has been updated? You can find the real one in `${N2ST_PATH}/src/function_library/general_utilities.bash`.
68
86
- Avoid mocking the `read` command. Instead use `echo 'y'` or `echo 'N'` for piping a keyboard input to the function who use the `read` command which in turn expect a single character, example: `run bash -c "echo 'y' | <the-tested-function>"`. Alternatively, use the `yes [n]` shell command which optionaly send [y|Y|yes] n time, example: `run bash -c "yes 2 | <the-tested-function>"`.
87
+
- Use `timeouts 10 ` in integration tests that execute real scripts with mocked dependencies to prevent test hangs.
69
88
70
-
### Instruction On Bats Tests
89
+
### Instructions On Bats Tests
71
90
- Use bats framework `bats-file` helper library provide tools for temporary directory management, such as the `temp_make` and `temp_del` functions.
### Shell Script specific Instructions On Tests Execution
103
+
All instructions in sections _General Instruction On Tests Execution_ plus the following:
84
104
- Don't directly execute `.bats` files, instead execute from the repository root `bash ./tests/run_bats_core_test_in_n2st.bash tests/tests_bats/<bats-file-name>.bats`.
85
-
- Don't set tests script in executable mode instead execute them with `bash <the-script-name>.bash`.
86
-
- Always run unit-tests before integration tests.
87
-
- Never run integration tests if any unit-tests fail.
105
+
- Don't set tests script in executable mode, instead execute them with `bash <the-script-name>.bash`.
106
+
107
+
## Python Specific Testing Instructions
108
+
All instructions in sections _General Testing Instructions_ plus the following:
109
+
1. Place new tests in the appropriate subdirectory based on what you're testing
110
+
2. Follow the existing naming conventions (`tests_*` for package, `test_*.py` for files, `test_*` for functions)
111
+
3. Use pytest fixtures from conftest.py for common setup/teardown if exist in directory or parent directory
112
+
4. Use parametrization for testing multiple scenarios
113
+
5. Regroup test function that tests different case of same function or class under a test class following the pytest test discovery naming convention like in the following example:
114
+
115
+
### Python Specific Instructions On Tests Execution
116
+
To run tests, use the pytest command from the project root or tests directory:
0 commit comments