Skip to content

Commit e83473a

Browse files
authored
CONTRIBUTING.md: Improve codestyle and testing section (#376)
Previously, the section "Codestyle and Testing" was outdated, still from the time where there was only the SDK inside this repository. This greatly extends the section, renaming it to "Code Quality" and introducing subsections for "Codestyle" and "Testing", where we describe how to run the necessary tests locally on the developer's machine for each of the packages inside this monorepository. Fixes #353
1 parent 8c46dfe commit e83473a

File tree

1 file changed

+69
-5
lines changed

1 file changed

+69
-5
lines changed

CONTRIBUTING.md

Lines changed: 69 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -119,16 +119,41 @@ The following guidelines are for the commit or PR message text:
119119
via `https://link/to.pdf#Page=123`
120120
- Optionally, where applicable reference respective issues: `Fixes #123`
121121

122-
## Codestyle and Testing
122+
## Code Quality
123123

124+
The Eclipse BaSyx Python project emphasizes high code quality.
125+
To achieve this, we apply best practices where possible and have developed an extensive suite of tests that are
126+
expected to pass for each Pull Request to the project.
127+
128+
### Codestyle
124129
Our code follows the [PEP 8 -- Style Guide for Python Code](https://www.python.org/dev/peps/pep-0008/)
125130
with the following exceptions:
126131
- Line length is allowed to be up to 120 characters, though lines up to 100 characters are preferred.
127132

128133
Additionally, we use [PEP 484 -- Type Hints](https://www.python.org/dev/peps/pep-0484/) throughout the code to enable type checking the code.
129134

130-
Before submitting any changes, make sure to let `mypy` and `pycodestyle` check your code and run the unit tests with
131-
Python's builtin `unittest`. To install the required tools, use:
135+
Before submitting any changes to the SDK, make sure to let `mypy` and `pycodestyle` check your code and run the unit
136+
tests with Python's builtin `unittest`.
137+
138+
### Testing
139+
There are many automated checks implemented in the CI pipelines of this project, all of which are expected to pass
140+
before new code can be added:
141+
142+
- We check that the Python packages can be built.
143+
- We run the developed unittests and aim for a code coverage of at least 80%.
144+
- We perform static code analysis for type-checking and codestyle, not just in the code itself, but also in codeblocks
145+
that are inside docstrings and the `README.md`.
146+
- We check that the automatically generated developer documentation compiles.
147+
- We check that the Python Versions we support match between the different subprojects in the monorepository and are
148+
not End of Life.
149+
- We check that the year in the copyright headers in each file (stemming from the license) is correct.
150+
151+
> [!note]
152+
> We strongly suggest to run the tests locally, before submitting a Pull Request, in order to accelerate the review
153+
> process.
154+
155+
### Testing the SDK
156+
For testing the SDK locally on your machine, you can install the required tools like so:
132157
```bash
133158
pip install .[dev]
134159
```
@@ -142,12 +167,51 @@ Running all checks:
142167
mypy basyx test
143168
pycodestyle --max-line-length 120 basyx test
144169
python -m unittest
170+
coverage run --source basyx --branch -m unittest
171+
coverage report -m
145172
```
146173

147-
We aim to cover our code with test by at least 80%. To check test coverage, you can use `coverage`:
174+
We aim to cover our code with tests by at least 80%.
175+
176+
This should help you sort out the most important bugs in your code.
177+
Note that there are more checks that run in the CI once you open a Pull Request.
178+
If you want to run the additional checks, please refer to the [CI definition](./.github/workflows/ci.yml).
148179

180+
### Testing the Server
181+
Currently, the automated server tests are still under development.
182+
To test that the server is working, we expect to at least be able to build the docker images and run a container
183+
of it without error.
184+
185+
For that, you need to have Docker installed on your system.
186+
In the directory with the `Dockerfile`:
149187
```bash
150-
pip install coverage
188+
docker build -t basyx-python-server .
189+
docker run --name basyx-python-server basyx-python-server
190+
```
191+
Wait until you see the line:
192+
```
193+
INFO success: quit_on_failure entered RUNNING state
194+
```
195+
196+
### Testing the Compliance Tool
197+
For the Compliance Tool, you can install the required tools like this (from the `./compliance_tool` directory):
198+
```bash
199+
pip install -e ../sdk[dev]
200+
pip install .[dev]
201+
```
202+
The first line installs the SDK and its dependencies, the second the developer dependencies for the compliance tool
203+
itself.
204+
205+
Then you can run the checks via:
206+
```bash
207+
mypy basyx test
208+
pycodestyle --max-line-length 120 basyx test
209+
python -m unittest
151210
coverage run --source basyx --branch -m unittest
152211
coverage report -m
153212
```
213+
214+
We aim to cover our code with tests by at least 80%.
215+
This should help you sort out the most important bugs in your code.
216+
Note that there are more checks that run in the CI once you open a Pull Request.
217+
If you want to run the additional checks, please refer to the [CI definition](./.github/workflows/ci.yml).

0 commit comments

Comments
 (0)