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
{{ message }}
Repository navigation
Migrate all mesh-related Ops from scijava-ops-image to imglib2-mesh #232
It would be best for the imglib2-mesh library to have static methods for doing all the mesh operations and statistics currently provided by scijava-ops-image e.g. in the geom3d subpackage. And they can be exposed as Ops by using @implNote op in the imglib2-mesh codebase. No need to keep them all locked up inside scijava-ops-image.
It would be nice to test that all declared Ops are actually available like we think they are...
This is a more general question than only the mesh/geom3d Ops, no? I.e. you are asking what our policy is on testing Op matching versus business logic behavior... right?
It looks like scijava-ops-image currently has 433 distinct Op names:
My feeling until now is that it is not critical for us to test that Ops are actually present in the environment and actually match. I recognize that that feels bad, but it would be a pretty boilerplate test, and there is a question of where it ends, w.r.t. all the various adaptations and conversions that can occur in matches.
If you disagree and would like to test that every declared Op successfully matches a down-the-middle request, I support that, as long as we introduce such matching tests as uniformly as possible across the entire suite of Opified components (scijava-ops-image, scijava-ops-flim, imglib2-mesh, imglib2-algorithm, etc.). Do you have thoughts on how you want to approach it? I would also prefer that we test matching only, rather than matching+execution.
If you disagree and would like to test that every declared Op successfully matches a down-the-middle request, I support that, as long as we introduce such matching tests as uniformly as possible across the entire suite of Opified components (scijava-ops-image, scijava-ops-flim, imglib2-mesh, imglib2-algorithm, etc.). Do you have thoughts on how you want to approach it? I would also prefer that we test matching only, rather than matching+execution.
Well the main thing that I want is to ensure that every @implNote turns into an OpInfo that could be matched - I don't think it's terribly important that we actually test the matching, because then there are other questions to answer e.g. priority. I'd think that could be automated easier...
Is something like the OpRegressionTest good enough? Where there is just one test that queries the environment for all available OpInfos, and checks that they match an expected list?
Is something like the OpRegressionTest good enough? Where there is just one test that queries the environment for all available OpInfos, and checks that they match an expected list?
I mean, yes, however we'd still have to figure out where that test lives. I think it should not live within imglib2-mesh, but then I have no idea where it would live.
Activity
gselzer commentedon Jun 10, 2024
@ctrueden how would you like to handle the tests? It would be nice to test that all declared Ops are actually available like we think they are...
ctrueden commentedon Jun 10, 2024
This is a more general question than only the mesh/geom3d Ops, no? I.e. you are asking what our policy is on testing Op matching versus business logic behavior... right?
It looks like scijava-ops-image currently has 433 distinct Op names:
only 244 of which are currently being tested to match:
My feeling until now is that it is not critical for us to test that Ops are actually present in the environment and actually match. I recognize that that feels bad, but it would be a pretty boilerplate test, and there is a question of where it ends, w.r.t. all the various adaptations and conversions that can occur in matches.
If you disagree and would like to test that every declared Op successfully matches a down-the-middle request, I support that, as long as we introduce such matching tests as uniformly as possible across the entire suite of Opified components (scijava-ops-image, scijava-ops-flim, imglib2-mesh, imglib2-algorithm, etc.). Do you have thoughts on how you want to approach it? I would also prefer that we test matching only, rather than matching+execution.
gselzer commentedon Jun 10, 2024
Well the main thing that I want is to ensure that every
@implNoteturns into anOpInfothat could be matched - I don't think it's terribly important that we actually test the matching, because then there are other questions to answer e.g. priority. I'd think that could be automated easier...ctrueden commentedon Jun 10, 2024
Is something like the
OpRegressionTestgood enough? Where there is just one test that queries the environment for all availableOpInfos, and checks that they match an expected list?gselzer commentedon Jun 14, 2024
I mean, yes, however we'd still have to figure out where that test lives. I think it should not live within imglib2-mesh, but then I have no idea where it would live.