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.
Merge pull request ARMmbed#405 from rojer/mfe #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
Merge pull request ARMmbed#405 from rojer/mfe #1
Changes from 1 commit
5a12c44f42e007ed8341e53d2b02626006aeeaf5361d2688ab06ce545181ce6ecc2857fb650579453ebdf4b6a6ba5d614fb9d069552ef0c1aab6aa0c8e9a644fb1883517d34177e307844d7112f9c2fd96a55084fe957de6530cb302c84acb69cf899f546f1f4b17b3dcae185c7987a3d04b077099029650fe8aea7dfae4cb261574677421d498b9f5e5b5d8f17d3d7f9dbec301e42abff849025137e4b6622f3d6372f5161214954a9bac438024d502881e52da340a7257681a049f131b033e95a9f38d4c9146eFile filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
This is the start of reworking littlefs's testing framework based on lessons learned from the initial testing framework. 1. The testing framework needs to be _flexible_. It was hacky, which by itself isn't a downside, but it wasn't _flexible_. This limited what could be done with the tests and there ended up being many workarounds just to reproduce bugs. The idea behind this revamped framework is to separate the description of tests (tests/test_dirs.toml) and the running of tests (scripts/test.py). Now, with the logic moved entirely to python, it's possible to run the test under varying environments. In addition to the "just don't assert" run, I'm also looking to run the tests in valgrind for memory checking, and an environment with simulated power-loss. The test description can also contain abstract attributes that help control how tests can be ran, such as "leaky" to identify tests where memory leaks are expected. This keeps test limitations at a minimum without limiting how the tests can be ran. 2. Multi-stage-process tests didn't really add value and limited what the testing environment. Unmounting + mounting can be done in a single process to test the same logic. It would be really difficult to make this fail only when memory is zeroed, though that can still be caught by power-resilient tests. Requiring every test to be a single process adds several options for test execution, such as using a RAM-backed block device for speed, or even running the tests on a device. 3. Added fancy assert interception. This wasn't really a requirement, but something I've been wanting to experiment with for a while. During testing, scripts/explode_asserts.py is added to the build process. This is a custom C-preprocessor that parses out assert statements and replaces them with _very_ verbose asserts that wouldn't normally be possible with just C macros. It even goes as far as to report the arguments to strcmp, since the lack of visibility here was very annoying. tests_/test_dirs.toml:186:assert: assert failed with "..", expected eq "..." assert(strcmp(info.name, "...") == 0); One downside is that simply parsing C in python is slower than the entire rest of the compilation, but fortunately this can be alleviated by parallelizing the test builds through make. Other neat bits: - All generated files are a suffix of the test description, this helps cleanup and means it's (theoretically) possible to parallelize the tests. - The generated test.c is shoved base64 into an ad-hoc Makefile, this means it doesn't force a rebuild of tests all the time. - Test parameterizing is now easier. - Hopefully this framework can be repurposed also for benchmarks in the future.Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
Uh oh!
There was an error while loading. Please reload this page.