Need to call asdf:load-system (or equivalent) from asdf:test-system

[Wilfredo Velazquez]

FYI mostly unrelated 2c - Opening issues for questions is not overkill IMO.
In fact it serves as a great knowledge base with discussion that is easily
searchable. Just close the issue when the question is resolved .

On Tue, Dec 28, 2021 at 10:52 PM Albus Matt Piroglu <mattapiroglu at gmail.com>
wrote:

> Note I have opened an issue on gitlab, but I know it's an overkill to open
> issues for questions. I couldn't find an appropriate channel until I found
> this mailing list. I'll close the issue, and here is my question for your
> consideration:
>
>
> Hi, I'm trying to test a functionality that depends on loading systems.
> Thusly I ended up writing some tests that need to load a "test-system"
> during the tests, and I clear the system afterwards.
>
> A simplified code for the test in question is:
>
> (test check-the-system-is-loaded-as-expected ()  (asdf:load-system "my-test-system-under-test-folder")  (is --check that the system loaded as expected--)  (asdf:clear-system "my-test-system-under-test-folder")  (delete-package "PACKAGE-FROM-TEST-SYSTEM"))
>
> and, to clarify, another test relies on the same system not being loaded,
> so I don't think a dependency would solve the issue, it is rather a dynamic
> decision to load or not.
>
> Now, I know that this feature is deprecated and may not work. What I'm
> wondering if there's a safer way to achieve this. Wouldn't some tests for
> asdf itself need loading some test systems for example? (hmm it actually
> might be a good idea to go check them now). OK, for example there's a
> hello-world-example.asd in test, which looks similar to my
> my-test-system-under-test-folder.
>
> So, instead of asdf:load-system in the above test code, should I be using
> a lower-level operation call?
>
> Thanks!
>
> Albus
>


-- 
Wilfredo Velázquez-Rodríguez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20211229/697e8896/attachment.html>