Initial integration tests#194
Conversation
License Check Results🚀 The license check job ran with the Bazel command: bazel run --lockfile_mode=error //:license-checkStatus: Click to expand output |
bfff457 to
784bdd7
Compare
|
The created documentation from the pull request is available at: docu-html |
* Add process args test eclipse-score#172 * Add run target switch test eclipse-score#174 * Add runtime crash test eclipse-score#177 * Add monitoring failure test eclipse-score#178 * Add crash on startup test eclipse-score#179
937434e to
f82bf7e
Compare
| int main() | ||
| { | ||
| deploy_and_crash_if_not_present("crashed_once"); | ||
| deploy_and_crash_if_not_present("crashed_twice"); |
There was a problem hiding this comment.
Where are these files being cleaned up again?
| derivation_technique="requirements-analysis", | ||
| ) | ||
| def test_crash_on_startup(target, setup_test, test_output_dir, remote_test_dir): | ||
| """Integration test verifying that the launch manager correctly handles processes |
There was a problem hiding this comment.
I think we need some more description of what is being tested here and what is the expected behaviour.
The process is asking for this information:
- The objective of the test.
- Inputs
- Expected outcome (e.g. “A success message is displayed.”)
- Test environment (e.g. network configuration, clean system state)
I know there is more info in control_client_mock.cpp available, but I assume we need this info in a test spec as part of a test report at least at a high level.
Maybe something like:
"""
Objective: Verifies that the launch manager correctly handles processes that crash before reporting kRunning.
Case 1: Process crashes before Running state but eventually starts up successfully before the configured number of restart attempts is exceeded.
Expected Behaviour: Process startup successful, RunTarget activation successful
Case 2: Process keeps crashing, exceeding the number of restart attempts.
Expected Behaviour: Process startup fails, LaunchManager executes recovery action.
"""| #include <score/lcm/control_client.h> | ||
| #include <score/lcm/lifecycle_client.h> | ||
|
|
||
| score::lcm::ControlClient client; |
There was a problem hiding this comment.
After merging #191 we cannot create the ControlClient in global scope as mw::log might not be initialized yet and does not support logging at this point in time.
Same for all other tests
Signed-off-by: Timo Steuerwald <142218678+TimoSteuerwaldETAS@users.noreply.github.com>
| TEST_STEP("Check args") | ||
| { | ||
| ASSERT_GT(g_argc, 1) << "Not enough arguments"; | ||
| EXPECT_STREQ(g_argv[1], "S-CORE rules!") << "Second argument was not as expected"; |
There was a problem hiding this comment.
Should this also check that the first argument is the binary name?
| TEST_STEP("Activate RunTarget Running") { | ||
|
|
||
| // We have to wait for the initial state transition to fully complete, otherwise unexpected failures can occur | ||
| sleep(1); |
| download_xml_results(target, remote_test_dir, test_output_dir) | ||
| all_files, failing_files = check_for_failures(test_output_dir) | ||
| assert len(all_files) == 2, f"Didn't find the expected number of files {all_files}" | ||
| assert len(failing_files) == 0, f"Found failures in files {failing_files}" |
There was a problem hiding this comment.
I wonder if we can abstract from this somehow.
This comparison of created files seems to be one of the main asserts deciding whether the test fails or succeeds.
Currently, it is based on comparing a raw number where it is easy to introduce one-off mistake. Maybe something like listing the components that were expected to start or something like that which is more explicit?
There was a problem hiding this comment.
Done in 55c9b98 , also updated them to use the fixture
96c73a1 to
84d0c5e
Compare
Implemented the following tests:
Improvements/fixes to test helper & smoke test