Add an option to enable the greentea tests independently from the unit
tests.
We can't just use the typical BUILD_TESTING option to enable greentea
tests. BUILD_TESTING enables unit tests and fetches googletest, which
are compiled for the host. Greentea tests are cross compiled and require
a toolchain file. For this reason we add a new option just to enable
greentea tests, preventing build failures triggered by the unit tests
and googletest.
Add tests for `sfdp_parse_sector_map_table()` which currently (at the
time of this commit) supports flash devices with
* no Sector Map Parameter Table (i.e. the whole flash is uniform and
non-configurable)
* a single descriptor in the Sector Map Parameter Table (i.e. the
flash layout is non-configurable and has multiple regions)
Support and unit tests for flashes with multiple configurable layouts
will be added in the future.
Note: The implementation of `sfdp_parse_sector_map_table()` assumes
the table to be valid if read succeeds, so the SFDP reader callback
needs to ensure it reads data correctly or return an error.
A flash device with no sector map table has uniform sectors, and we
treat the whole flash as one region. In this case the function
`sfdp_parse_sector_map_table()` sets the single region's size and high
boundary accordingly, but it lacks setting of region count to 1, so
users of the SFDP parser may not get the correct number of regions.
This commit fixes the issue.
When a flash chip's SFDP table has no sector map, we treat the whole
flash as a single region. As an optimization, this should only be
done if there is indeed no sector map.
Individual libraries' `target_h` stub headers have now all been moved
from `mbed-headers-base` to `mbed-headers-<library>`.
Note: Even though headers previously in `target_h` are technically
stubs/fakes too, they are used by not only unit tests but also regular
libraries when compiled for unit tests, because no target-specific HAL
implementation exists in this case. In order for regular library
sources to pick up `target_h` headers, those headers must
* have the same names as regular headers
* appear first in include paths
This is why those headers are part of `mbed-headers-<library>` and not
`mbed-stubs-<library>`. Before this refactoring, `mbed-headers-base`
was the first in unit tests' include paths.
Previously a test executable was recognised as a single test by CTest.
However, test executables usually contain multiple test cases, the
results of the test cases should be individually reported. With our
previous setup we could miss test case failures that didn't cause the
executable to return an error code.
This commit uses gtest_discover_test to discover all test cases in a
test executable. This enables CTest to match test passes and failures
from the googletest binary output.
Production code should not contain any test-specific checks. Rather
than checking `UNITTEST`, MbedCRC.h can simply include in all cases
<mstd_type_traits> whose unit test stub exists.
Also remove the `UNITTEST` macro from CMake definitions of kvstore
unit tests which depend on MbedCRC.h.
The CMake target `mbed-headers` brings in all headers, and we are
gradually moving away from it and explicitly use only headers needed
by each unit test.
The header `mbed.h` pulls in headers from a number of Mbed OS
components that are not necessarily used. It was intended for user
applications only, and libraries and unit tests should explicitly
include library headers it uses to limit dependencies.
This change avoids having to link unnecessary libraries in storage
unit tests' CMake definitions.
Move storage stubs from UNITTESTS/stubs into components inside the
top-level storage directory. Specifically,
* storage/blockdevice/tests/UNITTESTS/doubles/ for BlockDevice stubs.
* storage/kvstore/filesystemstore/tests/UNITTESTS/ for a stub used by
the FileSystemStore test. The stub has been renamed from
kv_config_stub.cpp to filesystemstore_kv_config_stub.cpp, to make it
evident why it doesn't go into storage/kvstore/kv_config/.
Assumption that greentea test file is always named main.cpp is
incorrect. Updated mbed_greentea_add_test() macro to make TEST_SOURCES
parameter compulsory, which is used to specify greentea test
file(s). This allows tests to use C, or have a different name.
Therefore also updated all pre-existing greentea test CMake files to
explicity add main.cpp to TEST_SOURCES.
Typically when adding a unit test directory to a CMake project a check
will be used to ensure the subdirectory is added only if the following
are true:
* The BUILD_TESTING option is set to ON.
* The current CMake project is the top-level project.
The reason being, if a downstream project includes our project they
generally don't want to build our unit tests.
In mbed-os, we do correctly specify the above condition before adding
the central UNITTEST subdirectory, which fetches googletest and adds the
"stub" libraries the unit tests depend on. However, we only check if
CMAKE_CROSSCOMPILING is OFF (or undefined) before actually adding the
unit tests. This mismatched logic would lead to unexpected build
failures in various scenarios. One likely case could be: a downstream
project including mbed-os happens to set CMAKE_CROSSCOMPILING to
OFF/undefined for any reason (possibly to build its own unit tests).
mbed-os would go ahead and attempt to build its tests without fetching
googletest or adding the required stub targets.
To fix the issue replace the check for CMAKE_CROSSCOMPILING in the unit
tests with the same BUILD_TESTING idiom we use for adding the central
UNITTESTS subdirectory.
- Remove redundant cmake script as already added the CMake configuration file
- Remove redundant empty_baseline as it is no longer needed with the help of CMake configuration file
The documentation previously referred to a weakly defined function
`storage_configuration`, however, this function was replaced at some
stage by `kv_init_storage_config`. Refactor the explanation on how to
override the default configurations to reflect this. Also, remove
the snippet which was used to show the implentation of
`storage_configuration`.
NO_RBP (no rollback protection) is intended to not require an internal
TDB, however, DeviceKey, which we use to derive SecureStore's
encryption key, still does. Currently, no internal TDB is created with
these two configurations, meaning there's no way to store the DeviceKey
and SecureStore doesn't work.
- LittleFileSystem.h and LittleFileSystem.cpp refers to the littflefs headers with the complete path like storage/filesystem/littlefs/littlefs/lfs_util.h and fixed the path issue
- ChainingBlockModuleTest test case compares two strings with EXPECT_EQ
which normally compare strings residing memory address so replaced it with EXPECT_STREQ to compare strings.
Each block of HeapBlockDevice is only allocated from the heap when
that block is programmed. And erasing a block frees the associated
buffer.
To decide if there is enough heap to run the TDBStore Whitebox tests,
we need to perform a trial program() instead of erase().
From the documentations of `BlockDevice::get_erase_value()`:
-1 if you can't rely on the value of the erased storage
and `BlockDevice::program()`:
The blocks must have been erased prior to being programmed
So, `BlockDevice::erase()` should always be called regardless of
erase value.
Robert Walton
Lingkai Dong
Martin Kojtal
ndrs-pst
Jaeden Amero
giulcioffi
Hari Limaye
rogeryou
Rajkumar Kanagaraj
Anna Bridge
harmut01
plan-do-break-fix