-
Notifications
You must be signed in to change notification settings - Fork 17
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
Add tests for computational_resources
module.
#448
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #448 +/- ##
===========================================
+ Coverage 39.69% 50.50% +10.81%
===========================================
Files 20 21 +1
Lines 3162 3249 +87
===========================================
+ Hits 1255 1641 +386
+ Misses 1907 1608 -299
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 1 file with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
I prefer to fix that bug in a follow-up PR. |
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.
@yakutovicha thanks a lot for testing this, very helpful. Just one request, all are good to me.
assert widget.on_setup_computer() | ||
|
||
# Check that the computer is created. | ||
computer = orm.load_computer("daint") |
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.
In this widget we combine setup phase and configuration phase, is this test still valid if the computer is setup but not run with configure? I think for in this test, we need to test and make sure the configure phase is hint and the computer in the DB is ready to use.
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.
Good point, @unkcpz. But the current widget is simply not supporting this use case. It deserves a PR on its own. Is it ok if we do that as a follow-up?
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.
Ah, I see, it is not possible to do it with the widget. I'd propose if you don't provide the configuration in the dict above it will fail in the configuration stage and you test the exception raised.
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 suggestion, done in 74f4751.
Just one clarification: I guess we don't want the visuals to raise an exception. They should rather print a message.
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 guess we don't want the visuals to raise an exception. They should rather print a message.
Indeed. 👍 The change looks great, thanks!
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.
It is all good from my side, thanks again this is very important test!
fixes #447