Skip to content

Commit

Permalink
Merge pull request #338 from FAIRmat-NFDI/docs-plugin-howto-fix
Browse files Browse the repository at this point in the history
Adds newlines to the list of steps
  • Loading branch information
sherjeelshabih authored Jun 3, 2024
2 parents 9650342 + 1bdab6b commit 3faf67b
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions docs/how-tos/using-pynxtools-test-framework.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Generalized Test Functionality for `pynxtools` plugins
The `pynxtools` sub-package `testing` is to be utilized to write automated tests for pynxtools reader plugins without requiring in-depth knowledge of the pynxtools internal architecture. The tool supports generalised a general test for all reader plugins, irrespective of the technical details of the raw data files and the internal design of the plugin (note: it is assumed that the plugin was built from the [plugin template](https://github.com/FAIRmat-NFDI/pynxtools-plugin-template) or has the same structure internally).
## Why it is needed
To test integration of a plugin with the `pynxtools` core system, we need to
1. Test the plugin's integration with `pynxtools` from the plugin's CI/CD.
To test integration of a plugin with the `pynxtools` core system, we need to:
1. Test the plugin's integration with `pynxtools` from the plugin's CI/CD.
2. Test in the pynxtools's CI/CD if the plugin has been integrated with `pynxtools` properly.
## How to write an integration test for a reader plugin with `pynxtools.testing`
It is very simple to write a test to verify the plugin integration with `pynxtools` within the plugin's tests directory. The developer can place the test where they want, but they need to use the provided test interface from `pynxtools`. An example test for `pynxtools-FOO` (a demo plugin) plugin is given below:
Expand Down Expand Up @@ -58,4 +58,4 @@ You can also pass additional parameters to `test.convert_to_nexus`:

- `log_level` (str): Can be either "ERROR" (by default) or "warning". This parameter determines the level at which the caplog is set during testing. If it is "WARNING", the test will also fail if any warnings are reported by the reader.

- `ignore_undocumented` (boolean): If true, the test skipts the verification of undocumented keys. Otherwise, a warning massages for undocumented keys is raised
- `ignore_undocumented` (boolean): If true, the test skipts the verification of undocumented keys. Otherwise, a warning massages for undocumented keys is raised

0 comments on commit 3faf67b

Please sign in to comment.