-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
reset StartUpCurrentLevel to ensure test repetitions #33921
base: master
Are you sure you want to change the base?
reset StartUpCurrentLevel to ensure test repetitions #33921
Conversation
PR #33921: Size comparison from 60ae46d to 80087c4 Full report (85 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, mbed, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
@@ -230,6 +233,16 @@ tests: | |||
type: int8u | |||
notValue: StartUpCurrentLevelValue | |||
|
|||
#This is a reset step that is needed to reset the value of the attribute to another value then the one used in 6b in order to ensure successful test repetitions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not great, since it introduces a divergence from the test plan in this certification test.
I know we have a step like that below already, but can we either get the test plan fixed to match the test or fix the way we run this test to match the test plan?
[TC-LVL-2.2] The added test step resets the StartUpCurrentLevel to another value then the one used in 6b.
Test step 6c checks if writing to the attribute StartUpCurrentLevel was successful by comparing its initial value with the value (5) written in step 6b. If the initial value and the value written in step 6b differ, the step is considered successful. However, if the test case is executed back-to-back, StartUpCurrentLevel remains unchanged between test runs, causing test step 6c to fail.