add first, user-triggered snapshot tests #218
Conversation
|
I am wondering if these tests will break with a next compiler release, because this might impact the program size, which is encoded e.g. here But it seems that it at least shows the same for the current nightly, so I guess this is a not-problem 😬 |
Since we're not re-compiling but running precompiled binaries that should be ok. If we ever recompile them then yes, we'll have to update the tests :D But I think that's actually a useful canary |
Lotterleben
force-pushed
the
local-tests
branch
2 times, most recently
from
c4b6d90
to
e69de8c
Compare
222: refactor the huge "main" function into smaller functions + module r=jonas-schievink a=japaric what the PR title says. I ran the ELFs from PR #218 and they print the expected output. This is the most non-trivial change that may have changed semantics - before we were extracting *two* RAM regions from the probe-rs registry. The "first one" (returned by the iterator) and the "one that contains the initial stack pointer (initial_sp)". we installed the canary on "the first one" but only if it contained the initial_sp - now, we only extract one RAM region, the one that contains initial_sp, and install the canary there I think this still does the same, in practice, but not 100% sure. Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com> Co-authored-by: Lotte Steenbrink <lotte.steenbrink@ferrous-systems.com>
|
@Lotterleben feel free to send this to bors after a rebase |
Lotterleben
force-pushed
the
local-tests
branch
2 times, most recently
from
3e08f6d
to
9b87ae3
Compare
|
bors r+ |
to try them out locally, connect an nrf52840 and run
cargo test -- --ignoredthese test cases are pretty basic to give us some sort of baseline and can be expanded in subsequent PRs. In the future it'd be cool to have them set up as hardware in the loop tests but I think they're already helpful during development as-is, even if we don't catch regressions automatically (yet)