-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #72 from rl-institut/feature-34-docs
Update documentation #34
- Loading branch information
Showing
20 changed files
with
385 additions
and
425 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
128 changes: 128 additions & 0 deletions
128
docs/development/best-practice/continuous_integration.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,128 @@ | ||
# Continuous Integration (CI) and Test Automation | ||
|
||
Continuous Integration (CI) ensures consistent code quality through automated | ||
testing, reporting, and deployments. <br> | ||
Our setup combines `GitHub Actions` and `tox` to streamline testing across | ||
environments, making the process robust and efficient. | ||
|
||
## GitHub Actions: Workflows | ||
|
||
GitHub Actions automates key workflows like testing, linting, and code | ||
quality checks. The CI pipeline includes the following tasks: | ||
- **Unit Testing**: Using `pytest` to ensure comprehensive test coverage. | ||
- **Code Formatting**: Validating syntax with `ruff`. | ||
- **Linting**: Verifying code style and docstrings with `ruff.lint`. | ||
- **Import Sorting**: Organizing imports with `ruff.lint.isort`. | ||
|
||
To set up GitHub Actions workflows for the repository, | ||
follow the [official GitHub guide](https://docs.github.com/en/actions/guides).<br> | ||
The GitHub Actions workflow is triggered on pull requests or commits to | ||
the `develop` or `production` branches. | ||
1. **Setup**: Prepares a Python environment and installs dependencies. | ||
2. **Testing**: Executes the `tox` automation suite to run the defined tests. | ||
3. **Reporting**: Generates detailed failure reports for debugging. | ||
|
||
GitHub Actions also automates documentation updates, ensuring the latest | ||
changes from the `develop` branch are reflected. For more details, see | ||
the [official GitHub Actions guide](https://docs.github.com/en/actions/guides). | ||
|
||
|
||
## Tox: Automating Testing | ||
|
||
[`tox`](https://tox.wiki/en/stable/) is a versatile tool for managing test | ||
environments and automating testing tasks across Python versions and operating | ||
systems (Linux, macOS, Windows). <br> | ||
It enhances reproducibility and reliability by creating isolated environments | ||
for testing: | ||
|
||
- **Virtual Environments**: Isolates dependencies for each Python version. | ||
- **Automated Testing**: Runs tests and style checks (for example, `pytest`, `ruff`). | ||
- **Cross-Version/Platform Testing**: Ensures compatibility across Python versions and operating systems. | ||
- **Dependency Management**: Customizes dependencies for diverse test scenarios. | ||
- **Reproducibility**: Maintains consistent workflows by way of 📝 `tox.ini`. | ||
- **Extensibility**: Supports plugins for custom functionality. | ||
|
||
### Install | ||
|
||
Install the required package in a python environment. <br> | ||
💻 `pip install tox` install tox <br> | ||
💻 `tox` run tox locally | ||
|
||
|
||
## Adding and Managing Tests | ||
|
||
New tests should be placed in the 📝 `tests/` directory. For example: | ||
- Add a test to validate new functionality. | ||
- Use `pytest` for unit tests, or extend 📝 `tox.ini` for additional test configurations. | ||
|
||
By combining `tox` and GitHub Actions, our CI pipeline ensures robust, | ||
reproducible, and scalable testing workflows. | ||
|
||
### Test Patterns | ||
|
||
1. **Unit and Integration Test** | ||
- **Purpose**: Test individual functions or methods. | ||
- **Framework**: `unittest`, `pytest` | ||
- **Example**: Simple function test and external API interactions. | ||
|
||
2. **Functional Testing** | ||
- **Purpose**: Test complete functionality (end-to-end). | ||
- **Framework**: `pytest`, `selenium` | ||
- **Example**: Test user login in a web app. | ||
|
||
3. **Mocking** | ||
- **Purpose**: Simulate external dependencies. | ||
- **Framework**: `unittest.mock`, `pytest-mock` | ||
- **Example**: Mock API calls in tests. | ||
|
||
4. **Acceptance Testing** | ||
- **Purpose**: Verify the software meets requirements. | ||
- **Framework**: `pytest`, `Behave` | ||
- **Example**: Verify login form functionality. | ||
|
||
5. **Performance Testing** | ||
- **Purpose**: Measure performance under load. | ||
- **Framework**: `pytest-benchmark`, `locust` | ||
- **Example**: Measure function execution time. | ||
|
||
6. **Security Testing** | ||
- **Purpose**: Test for security vulnerabilities. | ||
- **Framework**: `bandit` | ||
- **Example**: Scan for hardcoded passwords. | ||
|
||
7. **Snapshot Testing** | ||
- **Purpose**: Compare outputs to saved snapshots. | ||
- **Framework**: `pytest-snapshot` | ||
- **Example**: Compare function output snapshots. | ||
|
||
8. **Property-Based Testing** | ||
- **Purpose**: Test properties of functions with random inputs. | ||
- **Framework**: `hypothesis` | ||
- **Example**: Test that a sorting function always returns a sorted list. | ||
|
||
### Examples | ||
|
||
The file 📝 `tests/test_example.py` contains basic examples for the functions in <br> | ||
📝 `super_repo/test_calculator.py`. | ||
|
||
In Python, the `assert` statement is used to test if a condition is true. <br> | ||
If the condition is false, an AssertionError is raised, indicating the test failed. | ||
|
||
```python | ||
result = add(3, 4) | ||
assert result == 7 | ||
``` | ||
|
||
The `raises` context manager from the `pytest` library ensures that a ValueError is raised. <br> | ||
The `match` argument specifies that the error message matches the expected error pattern. | ||
|
||
```python | ||
with raises(ValueError, match=r"Cannot divide by zero"): | ||
divide(15, 0) | ||
``` | ||
|
||
We encourage contributions of additional tests and examples to help improve | ||
coverage and showcase different use cases—your input is valuable to enhancing the project! | ||
|
||
!!! note "Used Icons" | ||
🐙 GitHub | 💠 git | 📝 File | 💻 Command Line |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
# Best Practices | ||
|
||
Adopting best practices in software development enhances code quality, | ||
maintains consistency, and ensures reliability. <br> | ||
This section focuses on three key methodologies essential for maintaining | ||
high standards in a collaborative scientific software environment: | ||
|
||
- [**Continuous Integration (CI)**](https://rl-institut.github.io/super-repository/develop/development/continuous-integration/): <br> | ||
Automating the integration of code changes to catch errors early and maintain a stable codebase. | ||
CI ensures that all contributions are rigorously tested and integrated seamlessly into the project. | ||
|
||
- [**Test-Driven Development (TDD)**](https://rl-institut.github.io/super-repository/develop/development/continuous-integration/): <br> | ||
A methodology where tests are written before the actual code implementation. <br> | ||
TDD promotes robust and well-designed code by enforcing that each feature is accompanied by | ||
thorough testing from the outset. | ||
|
||
- [**Pre-commit Hooks (PCH)**](https://rl-institut.github.io/super-repository/develop/development/continuous-integration/): <br> | ||
Tools to enforce code | ||
quality and consistency by running checks or scripts before changes are committed. <br> | ||
These hooks help identify issues early, improving code hygiene and reducing technical debt. | ||
|
||
Following these practices will streamline development, reduce bugs, and foster a | ||
productive, collaborative coding environment. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
# Pre-commit Hooks | ||
|
||
Pre-commit hooks are tools used to enforce code quality and consistency by <br> | ||
running checks or scripts before changes are committed. <br> | ||
These hooks help identify issues early, improving code hygiene. | ||
|
||
## Installation and Setup | ||
|
||
Install the package in your base environment. | ||
💻 `pip install pre-commit` | ||
|
||
Create a 📝 `.pre-commit-config.yaml` file in your repository root. <br> | ||
This file defines the hooks and configurations. | ||
|
||
## Usage | ||
|
||
To run the hooks manually, use: <br> | ||
💻 `pre-commit run --all-files` | ||
|
||
Now, every time you commit changes, the pre-commit hooks will automatically <br> | ||
run the checks defined in your configuration file, ensuring code quality before | ||
committing. | ||
|
||
!!! note "Used Icons" | ||
🐙 GitHub | 💠 git | 📝 File | 💻 Command Line |
123 changes: 0 additions & 123 deletions
123
docs/development/best-practice/test-driven-development-workflow.md
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.