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
Copy file name to clipboardExpand all lines: docs/developers/contributing.md
+57-4Lines changed: 57 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,62 @@
1
-
# Testing Suite
1
+
# Contributing and Style Guide
2
+
3
+
## Docstring Style
4
+
5
+
### Functions and Methods
6
+
7
+
`causalprog` uses [Google-style docstrings](https://mkdocstrings.github.io/python/usage/docstrings/google/), which should be formatted as
8
+
9
+
```python
10
+
defmy_function(arg1, arg2):
11
+
"""
12
+
Summary line.
13
+
14
+
Further information in prose / paragraph format, mathematical notation is also supported here.
15
+
If some of the function arguments require detailed explanation, this explanation should be placed here.
16
+
17
+
Args:
18
+
arg1: Description of the first argument
19
+
arg2: Description of the second argument.
20
+
21
+
Returns:
22
+
Description of the object(s) that are returned by the method.
23
+
24
+
Raises:
25
+
ExceptionType: Conditions under which this is raised.
26
+
ExceptionType: Conditions under which this is raised.
27
+
28
+
"""
29
+
```
30
+
31
+
`mkdocs` also supports the `Tip:` and `Note:` syntax within docstrings too, which should appear within the further information section of the docstring.
32
+
33
+
If a function's purpose, return type, and inputs are clear from it's definition and name, then the docstring may consist of a single summary line instead:
34
+
35
+
```python
36
+
defsum_items(item1, item2):
37
+
"""Return the sum of two items."""
38
+
return item1 + item2
39
+
```
40
+
41
+
### Classes and Modules
42
+
43
+
Classes and modules should also obey Google-style docstring conventions where possible, but there is no need to provide an explicit listing of the methods (and / or attributes) that such objects provide in the docstrings themselves.
44
+
However, docstrings for classes and modules should still provide an adequate level of detail about what the module does / class represents, and the components that a user will typically be interacting with.
45
+
46
+
### Docstrings in the Tests and Examples
47
+
48
+
Outside the package source code, the docstring format is much more loose, though developers should try to stick to the Google-style when possible.
49
+
50
+
In the test suite; docstrings are typically used to describe the steps in longer, more involved tests, as well as the actual comparisons or `assert`ions that are made to ensure object being tested is functioning correctly.
51
+
52
+
In the examples; docstrings are typically provided in the summary format, relying on the surrounding prose to provide context for the reader.
53
+
54
+
## Testing Suite
2
55
3
56
`causalprog`'s test suite is written using [`pytest`](https://docs.pytest.org/en/stable/).
4
57
The package can be installed with its developer dependencies, including `pytest`, by specifying the `[dev]` optional dependency when installing the package.
5
58
6
-
## Running the tests
59
+
###Running the tests
7
60
8
61
To run the test suite, you will need to clone the `causalprog` repository and then install `causalprog` into your developer environment with the `[dev]` optional dependencies.
9
62
We recommend specifying an editable installation if you intend to make contributions to the package.
@@ -29,7 +82,7 @@ Running
29
82
30
83
in the repository root will do so.
31
84
32
-
## Organisation of the test suite
85
+
###Organisation of the test suite
33
86
34
87
The test suite contains a `fixtures` subdirectory, which is loaded as a `pytest` plugin when the tests are run.
35
88
All `pytest.fixture` objects defined inside the `fixtures` subdirectory (and subdirectories therein) are discovered by `pytest`, and available for use by individual tests.
@@ -49,7 +102,7 @@ Our general guidelines for organising unit tests are:
49
102
Any integration tests should be placed into the `test_integration` subfolder.
50
103
Again, this directory should contain a single file per integration test.
51
104
52
-
## Useful fixtures
105
+
###Useful fixtures
53
106
54
107
Some useful fixtures that are included in the `fixtures` directory;
0 commit comments