Integration testing using embedded-test #154
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds the basic structure for integration tests that run on actual hardware utilizing the embedded-test harness. This makes it possible to do "hardware-in-the-loop" testing very easily, thus being able to see if the hardware is behaving as the HAL expects and vice versa.
Marking this as a draft PR as I'd like to finish up the GPIO tests, ask some questions regarding hardware/HAL behaviour and find a good way to structure the tests for different hardware. While also checking if this sort of thing is desirable.
I am developing this against an STM32F401RETx, but it should be possible to transplant most of the logic to other hardware. Key differences being which GPIO pins should be used for the self-connected wires.