Skip to content

Conversation

@omlins
Copy link
Contributor

@omlins omlins commented Oct 22, 2018

Fixes #531.

Copy link
Contributor

@vkarak vkarak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix looks good, but we need a unit test that triggers the bug. We have a special regression test in the frontend_checks.py for emulating this behaviour: the BadSetupCheckEarly.

@omlins
Copy link
Contributor Author

omlins commented Oct 24, 2018

I could trigger the bug with the BadSetupCheckEarly and made a unit test.

@vkarak
Copy link
Contributor

vkarak commented Oct 24, 2018

@jenkins-cscs retry daint

self.assertEqual(max_retries, rt.runtime().current_run)
self.assertEqual(1, self.runner.stats.num_failures())

def test_retries_bad_check_early(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't this test be combined with the previous one? Just make it run both bad checks. The tests are almost identical.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea! I merged the two tests. Done.

# Ensure that the report succeeds and that the output is as expected.
report = self.runner.stats.retry_report()
self.assertIn("Test BadSetupCheckEarly was retried 2 time(s) and "
"failed.", report)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is quite restrictive. We will have to update the unit test every time we change either the automatic test naming scheme or message. I think we were getting a stack trace. You could then check that no Traceback is found in the output as we do with other similar cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the check is even easier here. I think retry_report() was raising an exception. So you may simply call it. If it raises an exception, the unit test will fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually wanted to do something like self.assertNoExcepetion(self.runner.stats.retry_report()) at that point but such an assert function does not exist, nor any similar. So I just do self.runner.stats.retry_report() instead, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you simply call. If an unexpected exception is thrown, the unit tests will fail.

Copy link
Contributor

@vkarak vkarak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @omlins, lgtm

@vkarak vkarak merged commit 05fa7a1 into reframe-hpc:master Oct 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants