Add the ability to create tests which can import microzig. #781
Conversation
What do you mean by this? Imo, we could provide a custom embedded test runner with microzig (I made a poc a while ago with this and it works pretty well - with error traces and everything). For pc ran tests, I think this patch is a fine solution. Is there a reason why you would want to import the full embedded microzig module on pc tests? An alternative could be to make a dummy one just to silent the microzig import error. |
|
I mean that I'm getting a build system error when I try to use the same path as the executable to make a module for the tests. I'm starting to like the test runner angle. I may have assumed the issue creator was trying to make host-run unit tests, but maybe they were also trying this. I'll get back to the drawing board tomorrow, I think I've got a better way to do this now. |
Fixes #230 This is really great, but I need some more eyes on whether this is how we want to do things. It seems that we have the limitation that our tests can no longer live within the same file as our executable. Using the modules directly from the Firmware object have linking errors because we are overloading the linker script (no _start symbol). And if I try to make a new module targetting the host using the same path, we get an error that multiple modules aren't allowed to have the same path. There might be a way around this that I'm not sure of. Otherwise, perhaps having to separate tests into their own files is an acceptable workaround? I imagine even if we magically fixed this, there would be many cases of linker errors, because of code depending on the embedded linkerscripts. Another pattern we might prefer is requiring any tests in the embedded executable to be run on the hardware itself. that would mean this patch should be providing a new test runner, and if a user wanted to write unit tests that ran on their PC, then they would have to put them elsewhere, which sounds reasonable to me.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🔍 Lint Results
ℹ️ Additional issues on unchanged lines
The following 4 issue(s) exist but are not on lines changed in this PR:
build.zig:405: TODO style comments need to have a linked microzig issue on the same line.
build.zig:647: TODO style comments need to have a linked microzig issue on the same line.
build.zig:687: TODO style comments need to have a linked microzig issue on the same line.
build.zig:703: TODO style comments need to have a linked microzig issue on the same line.
Fixes #230
This is really great, but I need some more eyes on whether this is how we want to do things. It seems that we have the limitation that our tests can no longer live within the same file as our executable. Using the modules directly from the Firmware object have linking errors because we are overloading the linker script (no _start symbol). And if I try to make a new module targetting the host using the same path, we get an error that multiple modules aren't allowed to have the same path.
There might be a way around this that I'm not sure of. Otherwise, perhaps having to separate tests into their own files is an acceptable workaround? I imagine even if we magically fixed this, there would be many cases of linker errors, because of code depending on the embedded linkerscripts.
Another pattern we might prefer is requiring any tests in the embedded executable to be run on the hardware itself. that would mean this patch should be providing a new test runner, and if a user wanted to write unit tests that ran on their PC, then they would have to put them elsewhere, which sounds reasonable to me.