|
| 1 | +# Testing 🧪 in Fiji / ImageJ2 |
| 2 | + |
| 3 | +Unfortunately there is nothing like `pytest` available for the parts that are |
| 4 | +running exclusively in a ImageJ2 / Fiji context. So in order to provide at least |
| 5 | +some basic, semi-interactive tests the following conventions are being used: |
| 6 | + |
| 7 | +* Each ***function*** in one of the `imcflibs.imagej` submodules should have its |
| 8 | + own directory underneath `/tests/imagej/`, using their fully qualified name |
| 9 | + as the path (only skipping the `imcflibs.` prefix). For example test scripts |
| 10 | + for `imcflibs.imagej.bioformats.import_image()` will be placed in the |
| 11 | + directory `/tests/imagej/bioformats/import_image/`. |
| 12 | +* The scripts inside those directories are intended to be run interactively / |
| 13 | + manually in a (freshly started) Fiji instance. Yes, really. Any other |
| 14 | + suggestions are highly welcome! |
| 15 | +* To facilitate this, a collection of *test images* (and possibly other input |
| 16 | + data) should be cloned to the local file system. Currently this `sample_data` |
| 17 | + repository is *NOT* publicly available due to legal ⚖ uncertainties. A repo |
| 18 | + containing test data 🗞 that can be published should be assembled over time |
| 19 | + though! |
| 20 | +* Any *interactive* test script should start with a header similar to the one |
| 21 | + described below. Paths to input data *inside* the test scripts **has** to be |
| 22 | + relative to the location of the `sample_data` repository mentioned above. This |
| 23 | + will allow for a fairly okayish testing workflow like this: |
| 24 | + * Make your changes in VS Code, then trigger a build by pressing `Shift` + |
| 25 | + `Ctrl` + `B`. If things are configured as described in the *DEVELOPMENT* |
| 26 | + document, the resulting `.jar` file will be automatically placed in Fiji's |
| 27 | + `jars/` folder. |
| 28 | + * Next, start a fresh instance of the Fiji that received the newly built JAR. |
| 29 | + * After Fiji has started, simply drag and drop the desired test script onto |
| 30 | + the main window. This will open the *Script Editor*, then press `Ctrl` + `R` |
| 31 | + to launch the script. |
| 32 | + * Only on the first run on the machine being used you will have to select the |
| 33 | + base location of the `sample_data` repository. |
| 34 | + * All subsequent runs of ***any*** test script using the defined *Script |
| 35 | + Parameter* `IMCF_TESTDATA` will remember this selection, so it will be |
| 36 | + sufficient to just confirm the dialog by pressing `Enter`. |
| 37 | + |
| 38 | +## Test Script Template 🏗 |
| 39 | + |
| 40 | +As described above, each test script should use the `IMCF_TESTDATA` parameter to |
| 41 | +facilitate the manual testing approach. Simply use this template header for |
| 42 | +creating new scripts (or look into existing ones): |
| 43 | + |
| 44 | +```Python |
| 45 | +# @ File (label="IMCF testdata location", style="directory") IMCF_TESTDATA |
| 46 | + |
| 47 | +import os |
| 48 | +from imcflibs.pathtools import join2 |
| 49 | + |
| 50 | +testfile = join2(IMCF_TESTDATA, "systems/lsm700/beads/10x_phmax.czi") |
| 51 | +assert os.path.exists(testfile) |
| 52 | +``` |
| 53 | + |
| 54 | +In case the test requires the components of the testfile's path to be used, this |
| 55 | +snippet will do the job: |
| 56 | + |
| 57 | +```Python |
| 58 | +# @ File (label="IMCF testdata location", style="directory") IMCF_TESTDATA |
| 59 | + |
| 60 | +import os |
| 61 | +from imcflibs.pathtools import parse_path |
| 62 | + |
| 63 | +components = parse_path("systems/lsm700/beads/10x_phmax.czi", IMCF_TESTDATA) |
| 64 | +assert os.path.exists(components["full"]) |
| 65 | +``` |
0 commit comments