These tests were removed because we didn't have a way to control the MRP flags and message sizes to the extent required by the tests.
Where possible, we should resurrect and automate these tests. Where this is not possible or desirable, we should prove at least SDK coverage of these tests using either artificial clusters (ex unit testing cluster) or by using unit tests against the secure channel components.
Tests to be revived:
[ ] TC-SC-1.1 - MRP Max message size (send a message of size 1280, send a message larger than 1280)
[ ] TC-SC-1.3 - MRP retransmissions - we can test this using nlFaultInjection and we can do it on CASE session establishment.
[ ] TC-SC-1.4 - MRP message counter and duplicate messaging - need plumbing to re-send messages outside of the retransmission framework
[ ] TC-SC-2.1 - PASE messages - This test should remove the verification on the DUT side and just verify the message contents that the DUT sends. We need plumbing to extract these messages.
[ ] TC-SC-2.3 - Error handling - can be done with nlFaultInjection. Might also want to make sure this error set is complete
[ ] TC-SC-3.3 - Error handling - as above
[ ] TC-SC-3.1 - This can be fairly easily automated provided the test case is just re-written to remove all the extra verbosity. Might also need to plumb through a close session message. Basically, esablish session, confirm it's ok, send close, re-establish using session resumption, confirm it's ok.
[ ] TC-SC-3.2 - I totally don't get how this is different from 3.1
[ ] TC-SC-3.3 - same as 3.1, but verifying the initiator. again, can be simplified
[ ] TC-SC-3.4 - this is just weirdly written because it's asking to validate things like "DUT receives message". Well, you know that as a byproduct of it sending back a response. This just needs pruning to verify actual things. Also needs plumbing to inject errors into the messages (nlFaultInjection)
These tests were removed because we didn't have a way to control the MRP flags and message sizes to the extent required by the tests.
Where possible, we should resurrect and automate these tests. Where this is not possible or desirable, we should prove at least SDK coverage of these tests using either artificial clusters (ex unit testing cluster) or by using unit tests against the secure channel components.
Tests to be revived: