Open arthur-shaw opened 7 months ago
This is what repado
is doing. With one but important difference. When installing .ado
files to the PLUS
folder, only the command sharing name with the file is made availible outside the file. This is what repado
is doing.
It is also possible to load all commands that are in an ado file (not just the one sharing the name with the file) to memory. This is done when executing do "path/filename.ado"
. However, this type of test simulates the real world user experience less well than what repado
is doing as all sub-command in the ado file is also made availible.
Using repado
to set up a dev testing environment creates a simulation identical to the real world users' experience.
What you are suggesting above is possible and not hard. But I do not think we should do it. Let me know if you still want me to do that.
Suggesting to not address this. repado
is included in the test-file template and is IMHO the best way to solve this. I'll let you close this issue if you agree. Or let me know if you see any concern relying on repado
.
For (interactive) testing, it would be good to automate a few otherwise manual actions:
src/ado
(e.g., find*.ado
files, run them).*.ado
fromsrc/ado
totests/plus-ado
In effect, this inspired from R's
devtools::load_all()
, which loads all functions from disk to memory. For interactive development, this loads functions into memory. For testing/checking, this does the same in a pipeline of actions (e.g., code health, rebuild documentaiton, etc.). See more here and here.