-
Notifications
You must be signed in to change notification settings - Fork 730
Refactor the CMake and related scripts for unit tests #4605
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
Merged
Merged
Changes from all commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
dac49c6
refactor: streamline CMake configurations and improve code coverage c…
lum1n0us 9162293
refactor: enable LLVM support across various CMake configurations
lum1n0us 387e101
fix: remove redundant LLVM dependency installation and add i386 suppo…
lum1n0us be9ba54
refactor: enhance CMake configurations for better build output and mo…
lum1n0us 00ef7fb
remove few wrong mocks from wasm_runtime_common_test_suite
lum1n0us 5cdd77f
refactor: update CMake configurations for custom section tests and wa…
lum1n0us 1e212d3
fix several reviewing comments
lum1n0us ad6e96b
Find llvm on demand
lum1n0us acac1ba
refactor: remove verbose flag from build command in CMakeLists.txt
lum1n0us ab9ddd6
add guidelines for creating a test suite in WAMR
lum1n0us 5e542ad
Roll back the previously removed code
lum1n0us 2b69648
docs: update test suite guidelines to clarify naming conventions for …
lum1n0us File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,37 @@ | ||
| # Copyright (C) 2019 Intel Corporation. All rights reserved. | ||
| # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
|
|
||
| function(check_ubuntu_version) | ||
| # ubuntu 2204 is the recommended environment for collecting coverage data for now | ||
| # otherwise, there will be ERRORs, when using 2404, like below and | ||
| # | ||
| # geninfo: ERROR: ('mismatch') mismatched end line for _ZN63compilation_aot_emit_memory_test_aot_check_memory_overflow_Test8TestBodyEv at /workspaces/wasm-micro-runtime/tests/unit/compilation/aot_emit_memory_test.cc:96: 96 -> 106 | ||
| # (use "geninfo --ignore-errors mismatch,mismatch ..." to suppress this warning) | ||
| # geninfo: ERROR: ('negative') Unexpected negative count '-3' for /workspaces/wasm-micro-runtime/core/iwasm/interpreter/wasm_interp_classic.c:5473. | ||
| # Perhaps you need to compile with '-fprofile-update=atomic | ||
| # (use "geninfo --ignore-errors negative,negative ..." to suppress this warning) | ||
| # | ||
| # For sure, `--ignore-errors` can be used to ignore these errors, but better to use the recommended environment. | ||
| file(READ "/etc/os-release" OS_RELEASE_CONTENT) | ||
| string(REGEX MATCH "VERSION_ID=\"([0-9]+)\\.([0-9]+)\"" _ ${OS_RELEASE_CONTENT}) | ||
| if(NOT DEFINED CMAKE_MATCH_1 OR NOT DEFINED CMAKE_MATCH_2) | ||
| message(WARNING "Unable to detect Ubuntu version. Please ensure you are using Ubuntu 22.04.") | ||
| return() | ||
| endif() | ||
|
|
||
| set(UBUNTU_MAJOR_VERSION ${CMAKE_MATCH_1}) | ||
| set(UBUNTU_MINOR_VERSION ${CMAKE_MATCH_2}) | ||
|
|
||
| if(NOT (UBUNTU_MAJOR_VERSION EQUAL 22 AND UBUNTU_MINOR_VERSION EQUAL 04)) | ||
| message(WARNING "Ubuntu ${UBUNTU_MAJOR_VERSION}.${UBUNTU_MINOR_VERSION} detected. Ubuntu 22.04 is recommended for collecting coverage data.") | ||
| else() | ||
| message(STATUS "Ubuntu 22.04 detected. Proceeding with coverage data collection.") | ||
| endif() | ||
| endfunction() | ||
|
|
||
| check_ubuntu_version() | ||
|
|
||
| # add compile options for code coverage globally | ||
| add_compile_options(--coverage -O0 -g) | ||
| link_libraries(gcov) | ||
| add_definitions (-DCOLLECT_CODE_COVERAGE) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,195 @@ | ||
| # Guide to Creating a Test Suite for a New Feature in WAMR | ||
|
|
||
| This guide provides instructions for contributors on how to create a test suite for a new feature in the WAMR project. Follow these steps to ensure consistency and maintainability across the test framework. | ||
|
|
||
| --- | ||
|
|
||
| ## General Guidelines | ||
|
|
||
| - **Create a New Directory**: | ||
| Always create a dedicated directory for a new feature under the `tests/unit/` directory. | ||
|
|
||
| - Reuse existing test cases and patch them when possible to avoid redundancy. | ||
| - Name the directory in lowercase with words separated by hyphens (e.g., `new-feature`). | ||
lum1n0us marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Name the test source file in lowercase with words separated by underscore (e.g., `new_test.cc`). | ||
|
|
||
| - **Avoid Committing `.wasm` Files**: | ||
| Do not commit precompiled `.wasm` files. Instead: | ||
|
|
||
| - Generate `.wasm` files from `.wat` or `.c` source files. | ||
| - Use `ExternalProject` and the `wasi-sdk` toolchain to compile `.wasm` files during the build process. | ||
|
|
||
| - **Keep Using `ctest` as the framework**: | ||
| Continue to use `ctest` for running the test cases, as it is already integrated into the existing test framework. | ||
|
|
||
| --- | ||
|
|
||
| ## Writing `CMakeLists.txt` for the Test Suite | ||
|
|
||
| When creating a `CMakeLists.txt` file for your test suite, follow these best practices: | ||
|
|
||
| 1. **Do Not Fetch Googletest Again**: | ||
| The root `unit/CMakeLists.txt` already fetches Googletest. Avoid including or fetching it again in your test suite. | ||
|
|
||
| 2. **Find LLVM on Demand**: | ||
| If your test suite requires LLVM, use `find_package` to locate LLVM components as needed. Do not include LLVM globally unless required. | ||
|
|
||
| 3. **Include `unit_common.cmake`**: | ||
| Always include `../unit_common.cmake` in your `CMakeLists.txt` to avoid duplicating common configurations and utilities. | ||
|
|
||
| Example: | ||
|
|
||
| ```cmake | ||
| include("../unit_common.cmake") | ||
| ``` | ||
|
|
||
| 4. **Use `WAMR_RUNTIME_LIB_SOURCE`**: | ||
| Replace long lists of runtime source files with the `WAMR_RUNTIME_LIB_SOURCE` variable to simplify your configuration. | ||
|
|
||
| Example: | ||
|
|
||
| ```cmake | ||
| target_sources(your_test_target PRIVATE ${WAMR_RUNTIME_LIB_SOURCE}) | ||
| ``` | ||
|
|
||
| 5. **Avoid Global Compilation Flags**: | ||
| Do not define global compilation flags in the `unit` directory. Each test case should specify its own compilation flags based on its unique requirements. | ||
|
|
||
| --- | ||
|
|
||
| ## Generating `.wasm` Files | ||
|
|
||
| - **Compile `.wasm` Files Dynamically**: | ||
| Use `ExternalProject` in your `CMakeLists.txt` to compile `.wasm` files from `.wat` or `.c` source files. | ||
| - Use the `wasi-sdk` toolchain for `.c` or `.cc` source files. | ||
| - Example configuration: | ||
| ```cmake | ||
| ExternalProject_Add( | ||
| generate_wasm | ||
| SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/wasm-apps | ||
| BUILD_ALWAYS YES | ||
| CONFIGURE_COMMAND ${CMAKE_COMMAND} -S ${CMAKE_CURRENT_SOURCE_DIR}/wasm-apps -B build | ||
| -DWASI_SDK_PREFIX=${WASI_SDK_DIR} | ||
| -DCMAKE_TOOLCHAIN_FILE=${WASISDK_TOOLCHAIN} | ||
| BUILD_COMMAND ${CMAKE_COMMAND} --build build | ||
| INSTALL_COMMAND ${CMAKE_COMMAND} --install build --prefix ${CMAKE_CURRENT_BINARY_DIR}/wasm-apps | ||
| ) | ||
| ``` | ||
| - **Example for `wasm-apps` Directory**: | ||
| Place your source files in a `wasm-apps/` subdirectory within your test suite directory. | ||
|
|
||
| - Create a `CMakeLists.txt` in `wasm-apps/` to handle the compilation of these files. | ||
| - Example `CMakeLists.txt` for `wasm-apps/`: | ||
|
|
||
| ```cmake | ||
| cmake_minimum_required(VERSION 3.13) | ||
| project(wasm_apps) | ||
|
|
||
| add_executable(example example.c) | ||
| set_target_properties(example PROPERTIES SUFFIX .wasm) | ||
| install(TARGETS example DESTINATION .) | ||
| ``` | ||
|
|
||
| --- | ||
|
|
||
| ## Compiling and Running Test Cases | ||
|
|
||
| To compile and run the test cases, follow these steps: | ||
|
|
||
| 1. **Generate Build Files**: | ||
|
|
||
| ```bash | ||
| cmake -S . -B build | ||
| ``` | ||
|
|
||
| 2. **Build the Test Suite**: | ||
|
|
||
| ```bash | ||
| cmake --build build | ||
| ``` | ||
|
|
||
| 3. **Run the Tests**: | ||
|
|
||
| ```bash | ||
| ctest --test-dir build --output-on-failure | ||
| ``` | ||
|
|
||
| This will compile and execute all test cases in the test suite, displaying detailed output for any failures. | ||
|
|
||
| 4. **List all Tests**: | ||
| To see all available test cases, use: | ||
|
|
||
| ```bash | ||
| ctest --test-dir build -N | ||
| ``` | ||
|
|
||
| 5. **Run a Specific Test**: | ||
| To run a specific test case, use: | ||
| ```bash | ||
| ctest --test-dir build -R <test_name> --output-on-failure | ||
| ``` | ||
|
|
||
| --- | ||
|
|
||
| ## Collecting Code Coverage Data | ||
|
|
||
| To collect code coverage data using `lcov`, follow these steps: | ||
|
|
||
| 1. **Build with Coverage Flags**: | ||
| Ensure the test suite is built with coverage flags enabled: | ||
|
|
||
| ```bash | ||
| cmake -S . -B build -DCOLLECT_CODE_COVERAGE=1 | ||
| cmake --build build | ||
| ``` | ||
|
|
||
| 2. **Run the Tests**: | ||
| Execute the test cases as described above. | ||
|
|
||
| 3. **Generate Coverage Report**: | ||
| Use `lcov` to collect and generate the coverage report: | ||
|
|
||
| ```bash | ||
| lcov --capture --directory build --output-file coverage.all.info | ||
| lcov --extract coverage.all.info "*/core/iwasm/*" "*/core/shared/*" --output-file coverage.info | ||
| genhtml coverage.info --output-directory coverage-report | ||
| ``` | ||
|
|
||
| 4. **View the Report**: | ||
| Open the `index.html` file in the `coverage-report` directory to view the coverage results in your browser. | ||
|
|
||
| 5. **Summary of Coverage**: | ||
| To get a summary of the coverage data, use: | ||
|
|
||
| ```bash | ||
| lcov --summary coverage.info | ||
| ``` | ||
|
|
||
| --- | ||
|
|
||
| ## Example Directory Structure | ||
|
|
||
| Here’s an example of how your test suite directory might look: | ||
|
|
||
| ``` | ||
| new-feature/ | ||
| ├── CMakeLists.txt | ||
| ├── new_feature_test.cc | ||
| ├── wasm-apps/ | ||
| | ├── CMakeLists.txt | ||
| │ ├── example.c | ||
| │ └── example.wat | ||
| ``` | ||
|
|
||
| --- | ||
|
|
||
| ## Additional Notes | ||
|
|
||
| - **Testing Framework**: Use Googletest for writing unit tests. Refer to existing test cases in the `tests/unit/` directory for examples. | ||
| - **Documentation**: Add comments in your test code to explain the purpose of each test case. | ||
| - **Edge Cases**: Ensure your test suite covers edge cases and potential failure scenarios. | ||
| - **Reuse Utilities**: Leverage existing utilities in `common/` (e.g., `mock_allocator.h`, `test_helper.h`) to simplify your test code. | ||
|
|
||
| --- | ||
|
|
||
| By following these guidelines, you can create a well-structured and maintainable test suite that integrates seamlessly with the WAMR testing framework. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.