tests: drivers: uart: config api has extra dependency in test 2

[jenmwms]

Is your enhancement proposal related to a problem? Please describe.
Tests were added for the UART configure API in - tests: drivers: uart: config api #22849. The existing test implementation works, but the 2nd case: ”test_config_get()” will fail if we don’t run the 1st case :” test_uart_configure()” because the 2nd case have not set the value for the variable :”uart_cfg_check”.

Describe the solution you'd like
Suggest to make each case's independence as possible.

Describe alternatives you've considered
From comment in original discovery #22849 -

• For the 1st case , we may only force on testing for setting configuration, so we may use the 1st case from your last version: 6c1156d to name test case: “test_uart_config_set()”.
• For the 2nd case, we may use the 1st case from your new version: 721ce3a as 2nd test case, then name test case:”test_uart_config_get()”, and I have few comments below for the case’s last part.

Could you please help also review the code below ?
================last part code ==================
/* Verify configure() - set device configuration using data in cfg /
int ret = uart_configure(uart_dev, &uart_cfg);
zassert_ture(ret == 0, "set config error");

/ Confirm the values provided are the values set*/
ret = uart_config_get(uart_dev, &uart_cfg_check);
zassert_ture(ret == 0, "get config error");

if (memcmp(&uart_cfg, &uart_cfg_check, sizeof(uart_cfg)) != 0) {
return TC_FAIL;
} else {
return TC_PASS;
}
==============End last part code ==================

Additional context
tests: drivers: uart: config api #22849, included checking that the values stored and retrieved are as expected after calling the functions under test. The functions under test offer return values of success or error, which does not easily lend itself to check the stored/retrieved value in addition to the return value.

[jenmwms]

@xuhao8210 We can continue the discussion from #22849 here and resolve it with a PR. Thanks!

[xuhao8210]

@jenmwms OK. got it .Thanks Jen. if any comments for my suggestion, please let me know. Thanks again.

[jenmwms]

@xuhao8210 Thanks for suggesting changes. I agree with the approach, however I have a comment about renaming the 1st case to test_uart_config_set(). There is not a config_set() in the uart configure API.

• Is it breaking any test framework guidelines? IME the style is test_<api_function_name>().
• Middle ground is test_uart_configure_set() so we still use the relevant function name but indicate something slightly different is happening in that test.

I'll submit a PR soon

[jenmwms]

Why do we need to rename the first case? We have 2 test cases:

1. test_uart_configure()
2. test_uart_config_get()

[jenmwms]

<For the 1st case , we may only force on testing for setting configuration, so we may use the 1st case from your last version: 6c1156d to name test case: “test_uart_config_set()”.>

So we do not (or cannot) verify the 1st test works (configure()) by checking a value? Because we need to use the partner function config_get() to retrieve the value we want to check effected by configure().

[xuhao8210]

@jenmwms For the test case name, you are right, and I forgot the name style, originally I would like to make the test case to better understand based on test case name. So please keep the test case name. Sorry for making you confuse. Thanks.

[xuhao8210]

@jenmwms For the 1st test case issue, if the 1st case is also include the checking point that it checks whether output value is same with the input value, the 1st case will same with 2nd case.
Personally I think that one case is enough because the 2nd case have covered the 1st case’s test point (e.g. refer the 2nd case in the PR: 23509), so I had ever given the comment : "we may merger the 2 test cases into one case , then add one checking point” in the PR: 22849.
But I think that it is also fine if there are 2 test cases for the test because I checked that other tests are also include 2 test cases. (e.g. “test_uart_fifo_read()” and “test_uart_fifo_fill()”), maybe we can keep the same style.
And I think that it is fine after I reviewed the newest PR: 23509. Thanks for your time to review my comments.