I like to include the code that I use to test a subroutine as a disabled group the subroutine macro itself. That way the test code stays with the macro. I then copy the group, paste it in a separate macro, and run it.
It would be very handy to be able to select the disabled group and run (try) it directly. Then testing a subroutine, during development or in the future, would be no more than a couple of clicks.
What's the actual problem? Using "Try" on a "Group" appears to run all the actions in that Group (of course, it does have to be enabled). The main issue will be the same as with "Try" in general -- because it is being run in isolation you may not have the full context required, such as previously-set variables or %ExecutingMacroUUID%.
But perhaps I'm misunderstanding -- have you got an example?
Sure. The subroutine sub_Find-Image below finds an image, allowing the various Found Image parameters to be set by values rather than sliders and checking boxes. But that doesn't really matter.
The import part is the disabled block named TEST CODE - Copy to Macro and Run. This block contains test code to call the subroutine with some set of parameters. As above, I like to keep code for testing a subroutine with the subroutine itself so I have it for future modifications or if the code acts up.
For obvious reasons, when the subroutine is called this block of code has to be disabled. This is a very simple example.
To use the code as things stand, I have to copy it, place it in another macro, and then run that macro. Then when I am done I have to copy the modified test code and restore it in the subroutine.
It would greatly simplify this process if all I had to do was select the disabled block containing the test code and run it.
I understand that this would be an issue if the disabled block were part of a number of selected statements that were to be tried. One option would be to add a statement status other than enabled and disabled and a version of try that only runs those statements. Another would be to add a new version of the Group statement that only runs with try, and then only when it and it alone is selected.
A quick solution would be to allow a disabled group to be run with try, but only if it is the only thing selected.
Likewise for the disabled OPEN OBSIDIAN NOTES block, which calls an Open URL action that opens the file in an Obsidian vault.
Well, I'm not going to try and reproduce that!
How about a different approach? All you really need to do to test your sub-routine is to run it in the Editor, inject the parameter values that would normally be provided by the caller, and display the result. So you could start with an "If" block that tested eg localImageFilePath (assuming that was always set under "normal" ops) and set a local_testing flag as appropriate. You could then test that flag at other points in your sub-routine and set your fake parameters, open the Debugger, "Display" the final result or return it to the caller...
Example. "Subroutine Test" would be your normal caller, "SUB - Test" the sub-routine which you can also run in the Editor for testing:
Subroutine Test.kmmacros (2.8 KB)
SUB - Test.kmmacros (7.0 KB)
Thanks for the suggestion. That is a good direction to take! (Don't ask me why I didn't think of that...)
Here is a template to use for any subroutine. It can contain as many different blocks of test code as you like. To run a test, select one of the green groups and execute it with try. The if action will always fail inside the subroutine.
