Fixing extension testing failures

Hi,
there are a number of tests in the SlicerDMRI extension build that I would like to fix:
CDash

Some of them (e.g. py_TractographyExportPLY, py_TractographyDownsample) report a short message saying

[/Users/svc-dashboard/D/S/A/Slicer-build/bin/Slicer.app/Contents/MacOS/./Slicer] exit abnormally - Report the problem.

I’ve found these potentially related threads, and have read the information in the corresponding links:
PythonSlicer problem with vtk and ReadData · Issue #6484 · Slicer/Slicer · GitHub
Extension tests fail on CDash, why? - #13 by RafaelPalomar

However, it is unclear what the appopriate sorting for the imports is: is this documented somewhere? Otherwise, what is the recipe? I have tried a few different sortings without success for e.g.:
https://github.com/SlicerDMRI/SlicerDMRI/blob/372675b96e917acb61bc8cb2ac9262d87cc5b06a/Modules/Scripted/TractographyExportPLY/TractographyExportPLY.py#L6
https://github.com/SlicerDMRI/SlicerDMRI/blob/372675b96e917acb61bc8cb2ac9262d87cc5b06a/Modules/Scripted/TractographyDownsample/TractographyDownsample.py#L9

Also, there are a number of tests (e.g. py_fiber_visibility_crash2438) that fail because data nodes are not available in the scene, e.g.

 tractNode = slicer.util.getNode('tract1')
 (...)
 slicer.util.MRMLNodeNotFoundException: could not find nodes in the scene by name or id 'tract1'

I’ve seen that the data does not get loaded into the scene (it does if I use a ModelFile type, but then fails to get other fiber data type-specific properties):
https://github.com/SlicerDMRI/SlicerDMRI/blob/372675b96e917acb61bc8cb2ac9262d87cc5b06a/Modules/Loadable/TractographyDisplay/Testing/Python/fiber_visibility_crash2438.py#L191

The command looks correct, though. What am I missing here? How can this be tested properly/fixed?

Note that the data was moved (related topic Actual data content of slicer.kitware.com-midas3-archive) and the correct uris for the data would be https://github.com/Slicer/slicer.kitware.com-midas3-archive/releases/download/SHA256/06d5b5777915857fbac7b3cbd9c371523d1371f29b0c89eb7a33d86d780d5b2b.

Thanks.

Are you able to replicate the test crashes in a local debug build?

Regarding the import order difference maybe you can join one the Tuesday morning developer meeting and we can discuss. It should just be a matter of following the class hierarchy and library dependencies.

Thanks for answering Steve.

Have not tried debugging; I am able to reproduce the issue from a command line run. Have read the debugging instructions in the Slicer documentation, but it is unclear to me how this can be debugged (this being an extension, this being a Python module, etc.).

Have a meeting 11:00-12:00 ET. If it does not conflict, I may join.