Honestly, with the tests being split out individually, I think it's actually okay the way it is. If any test throws an error it does show pretty clearly which test caused the error and which assert statement inside the function was tripped.

I'm not sure exactly what happens inside the test environment, but I don't think creating globals are necessarily the best way to go. This function uses a persistent variable, I don't know how that does or doesn't function in the test environment compared to in a normal function either, but it didn't seem to cause problems.

ok.  I played around with it a bit, I also didn't see a better way to test that functionality than how you did it. all 6 asserts get hit in the tests you created, so I don't think it's any messier than the rest of the tests in those functions.

the only changes I made were to divide up the test block into 3 individual test blocks. this will make it a bit clearer which block is creating the error if one occurs.

adjusted patch attached. passes all tests, and I remembered to keep your name on it :)

Requesting someone else push it if it looks good, though. It's just a BIST change and should be fairly low impact, but I'm not sure where things are right now in the current state of octave 8 release after the branches were merged.

(file #53967)

I agree that this is generally not the preferred form for the test, but I'm not sure any alternatives are more appealing. The problem is that the output of OutputSel function is not returned directly to the outputs of ode{xx}.

Other than just not having a test (the status quo), the only other way to test the OutputSel implementation without changing the code is to have the OutputFcn return the stop signal (stop_solve) if there is a problem. We could then test whether the final output of ode{xx} is the expected value, and infer an error if not. If there is an error, we know that there was a failure in the intermediate steps (flag==""). However, the return value of stop_solve is ignored in the flag=="init" and flag=="done" calls, so without raising an error in OutputFcn itself, problems in those calls are not testable.

I suppose another alternative would be to change the source code to query the value of stop_solve more more than just true/false at each OutputFcn call, but I'm pretty sure that would break Matlab compatibility and generally cause more problems than it fixes. Or we could pass any nonzero return values of stop_solve down the line and put it into the output struct of ode{xx}. It would be extra code/overhead and an undocumented feature, but probably wouldn't break compatibility.

Now that the dependency bug is marked fixed, presumably this one is ready for testing.

updating status and adding the dependency on bug #63063.  Does this also need to be applied after any patches in bug #63162 or are they independent?