-
Notifications
You must be signed in to change notification settings - Fork 304
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
DAOS-15841 control: Improve coverage and fs mocking in storage packages #14379
Conversation
Ticket title is 'Improve test coverage and filesystem mocking in storage packages' |
Test stage Build on Leap 15.5 with Intel-C and TARGET_PREFIX completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/1/execution/node/381/log |
Test stage Build on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/1/execution/node/386/log |
936d31d
to
5aa4b3c
Compare
Test stage Build RPM on EL 9 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/1/execution/node/342/log |
Test stage Build RPM on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/1/execution/node/308/log |
Features: control Required-githooks: true Signed-off-by: Tom Nabarro <[email protected]>
5aa4b3c
to
1274a61
Compare
Test stage Build on Leap 15.5 with Intel-C and TARGET_PREFIX completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/3/execution/node/387/log |
Test stage Build on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/3/execution/node/359/log |
Test stage Build RPM on EL 9 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/3/execution/node/343/log |
Test stage Build RPM on Leap 15.5 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/3/execution/node/380/log |
Test stage Build RPM on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/3/execution/node/339/log |
Test stage Build DEB on Ubuntu 20.04 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14379/3/execution/node/355/log |
…adfile-mocking Features: control Required-githooks: true Signed-off-by: Tom Nabarro <[email protected]>
…kage SystemProvider interfaces Features: control Required-githooks: true Signed-off-by: Tom Nabarro <[email protected]>
…adfile-mocking Features: control Signed-off-by: Tom Nabarro <[email protected]>
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.
Wouldn't block on my comment, but it is something to think about. Everything else looks okay.
StatErrors map[string]error | ||
RealStat bool | ||
ReadFileResults map[string][]byte | ||
ReadFileErrors map[string]error | ||
RealReadFile bool |
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.
I see RealStat
already exists up there, but I don't feel great about adding this kind of complexity to a single mock struct, to toggle the real version of the function on and off. IMO, if there are certain tests that want some real and some mocked functions, those tests should create their own mock struct to customize the behavior.
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.
From my understanding, it seems to have the advantage to factorize this mocking code and the complexity seems to still be acceptable.
However, as I am not a GO expert, I am probably missing something.
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.
@knard-intel those were my thoughts when adding the flag. After chatting with @kjacque I can see benefit in moving to smaller package-local (as @mjmac also suggested elsewhere) SystemProvider mocks which would be consistent with having package-level SystemProvider interfaces. I will make changes if I have to repush or the next time I visit this area.
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.
Make sense, thanks for the explanation :-)
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.
LGTM
Some control-plane storage unit tests are inadvertently calling into
test runner host OS filesystem. Fix by consolidating SystemProvider
interface and applying storage subsystem provider stubs by default
in the unit test framework. As a result coverage can be improved by
exercising a greater number of code paths.
Features: control
Required-githooks: true
Before requesting gatekeeper:
Features:
(orTest-tag*
) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.Gatekeeper: