-
Notifications
You must be signed in to change notification settings - Fork 3k
TCP/UDP greentea tests refactoring and cleanup #9376
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
Conversation
425772a
to
281eb3e
Compare
tools/test_configs/no_network.json
Outdated
}, | ||
"echo-server-discard-port" : { | ||
"help" : "Discard port of echo server", | ||
"value" : "9" |
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.
Please see value of the "echo-server-port" and the name of the file.
static void _sigio_handler(osThreadId id) | ||
{ | ||
osSignalSet(id, SIGNAL_SIGIO); | ||
if (event_queue != NULL) { | ||
event_queue->call(tcpsocket_echotest_nonblock_receive); | ||
} | ||
} |
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.
Should here either be an else-clause or the event_queue.call() doesn't need to be wrapped on if-clause
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.
Again, never mind... Once you register the SIGIO handler it might be that you don't have a handle to event queue yet.
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.
Thanks for the remark. I changed the order of test initialization, so that the event queue gets created before we register the sigio handler.
Nevertheless, to be on the safe side, I left the NULL check and added an else statement that raises an error in case the NULL check fails :)
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.
ok :) This is not a suggestion to change anything but using TEST_FAIL_MESSAGE indicates there is a problem with the implementation under test. But, actually the issue would be with the test case implementation itself. MBED_ASSERT or MBED_ERROR might be good alternatives here.
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 a very good point, thanks for that, but I think it makes some sense to stay with TEST_FAIL_MESSAGE.
Firstly, it is not that obvious to me that the error must come from the test code. What if the handler didn't get unregistered correctly or if the EventQueue creation is erroneous?
Also, MBED_ASSERT/ERROR will crash the whole test suite and I find this reaction too serious, given the circumstances.
I hope you're ok with this? :)
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.
Fine by me :)
int recvd = sock.recv(&(tcp_global::rx_buffer[bytes2recv_total - bytes2recv]), bytes2recv); | ||
if (recvd == NSAPI_ERROR_WOULD_BLOCK) { | ||
if (tc_exec_time.read() >= time_allotted) { | ||
receive_error = true; |
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.
tx_sem isn't released here. Sender might end up waiting forever as the timeout was removed.
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.
We don't really want to release the semaphore in case of WOULD_BLOCK - we want to wait until the data arrives. Therefore, I added the timeout back, but fixed it to the correct units.
I hope this is fine? :)
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.
ok, that's fine.
}, | ||
"echo-server-discard-port" : { | ||
"help" : "Discard port of echo server", | ||
"value" : "9" |
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.
Hi
I am using a local test network.
Is this new setting need some new configuration command to my server ?
Thx
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 port number is the same as what was used earlier. The only difference is that instead of it being hardcoded now it can be configured.
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.
Hi,
No, there is no need to change the network/server configuration.
The tests were so far using the same port number, but it was coded explicitly, like so:
tcp_addr.set_port(9);
Now it is defined in the config file, to avoid magic numbers, like so:
tcp_addr.set_port(MBED_CONF_APP_ECHO_SERVER_DISCARD_PORT);
281eb3e
to
59e8ded
Compare
CI started |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
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.
👍
@michalpasztamobica Can you talk to @OPpuolitaival about this new config addition (our nightly fails as new config addition is not defined there). |
Fix already created and under review |
I've seen the fix and it makes sense. Sorry for breaking the build, I didn't know there are external configs in use in CI, I assumed everyone would use the ones we provide. Next time I will notify @OPpuolitaival in advance. |
We can try to use configuration more flexible way |
Description
When adding TLSSocket greentea tests recently in #9283, there was a number of review remarks. Those tests were based on TCPSocket, so most of the review remarks apply there and some to UDPSocket greentea tests, too.
Pull request type
Reviewers
@SeppoTakalo
@VeijoPesonen