Skip to content
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

Adding test suite for testing IBMQJob in isolation. #515

Merged
merged 4 commits into from
Jun 21, 2018

Conversation

delapuente
Copy link
Contributor

@delapuente delapuente commented May 28, 2018

The test suite does not require a network connection. It fakes the QJOB object and the API behaviour.

This commit partially refactors the IBMQJob#status() method to avoid raising exceptions while reading a property.

Motivation and Context

Current tests behave as integration tests so, in case of failure, it is not guaranteed the problem arises from IBMJob-related abstractions malfunctioning.

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.


def run_job(self, *_args, **_kwargs):
time.sleep(0.2)
return {'error': 'ivalid test qobj'}
Copy link
Member

Choose a reason for hiding this comment

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

typo here "invalid"

@delapuente delapuente force-pushed the test-ibmqjob-in-isolation branch from 0becd31 to a105d5b Compare May 29, 2018 15:57
# pylint: disable=arguments-differ
def result(self, timeout=60, wait=5):
self._wait_for_initialization(timeout=timeout)
result = self._wait_for_job(timeout=timeout, wait=wait)
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 expectation for timeout will be the maximum time for the result call to return. Perhaps we can instead start a clock here (timeout_time = time.time() + timeout) and pass timeout_time to _wait_for_initialization and _wait_for_job.

if self._future_submit.exception():
self._exception = self._future_submit.exception()
self._status_msg = str(self.exception)

Copy link
Contributor

Choose a reason for hiding this comment

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

How does this PR handle exceptions raised by self._future_submit which is done async and may occur later?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Notice that reading status will be stuck in the INITIALIZING state until the initialization routine _submit changes the internal job status.

All the errors happening inside the _submit() are silenced (except for one case I just realize, thanks!) and stored inside the _exception member, the internal status progress to JobStatus.ERROR in these cases.

This causes all future reads to status to skip querying the API since the job is in one of the final states.

Both tests test_status_flow_for_invalid_job and test_status_flow_for_throwing_api test the job in the cases when the job is invalid (and the API rejects it by raising an ApiError) or the network side fails somehow (and the API returns an errored result) respectively. Anyway, I'll reinforce the tests in the next commits, checking the exceptions to get more confidence in the paths we are following.

Hope it helps.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is an error in my assumptions regarding _submit() progressing the job to a final state. This final assignment happening at the end of the method invalidates de second paragraph of the explanation. I'll fix in the next commit. Thanks for the heads-up.

@delapuente delapuente force-pushed the test-ibmqjob-in-isolation branch 2 times, most recently from ffd3ba0 to acdfd57 Compare June 4, 2018 15:22
@delapuente
Copy link
Contributor Author

Everything is fixed now. What about a second review?

@diego-plan9 diego-plan9 mentioned this pull request Jun 6, 2018
5 tasks
@diego-plan9 diego-plan9 added this to the 0.5.x milestone Jun 6, 2018
@delapuente delapuente force-pushed the test-ibmqjob-in-isolation branch 4 times, most recently from a3fd9e7 to e13056d Compare June 8, 2018 07:47

"""IBMQJob states test-suite."""

import unittest
Copy link
Member

Choose a reason for hiding this comment

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

For the new files, can you adjust the license header so it follows the format recently introduced by #550 ?

# -*- coding: utf-8 -*-

# Copyright 2018, IBM.
#
# This source code is licensed under the Apache License, Version 2.0 found in
# the LICENSE.txt file in the root directory of this source tree.

# pylint: disable=something-only-if-there-is-no-other-way

"""
Description of the module ...
"""
from qiskit import ...

@delapuente delapuente force-pushed the test-ibmqjob-in-isolation branch from e13056d to bf0efec Compare June 8, 2018 17:35
ewinston added a commit to ewinston/qiskit that referenced this pull request Jun 15, 2018
This commit incorporates improvements from PR Qiskit#515 by @delapuente to handling job status such that it makes fewer api calls.

Co-authored-by: [email protected]
@delapuente delapuente force-pushed the test-ibmqjob-in-isolation branch from bf0efec to 9eaf078 Compare June 18, 2018 10:30
@atilag
Copy link
Member

atilag commented Jun 18, 2018

@delapuente @ewinston not sure how to handle this PR. As this is going to test Jobs, and Ericks PR #501 (jobs from Backend) is hughly changing IBMQJob... we would need to have them sync.
My proposal is: ... as this is a PR about testing, I would merge this one fist and then rebase and solve conflicts on #501. Does it sound good?

@ewinston
Copy link
Contributor

Since #501 is tagged as "high priority" and it's an earlier PR perhaps it should be the other way around.

@delapuente delapuente force-pushed the test-ibmqjob-in-isolation branch from f5daa11 to 06c3a10 Compare June 20, 2018 15:19
@ajavadia
Copy link
Member

@delapuente is this PR rebased after #501 got merged?

@ajavadia
Copy link
Member

Does this solve #234?

@delapuente
Copy link
Contributor Author

delapuente commented Jun 21, 2018

@delapuente is this PR rebased after #501 got merged?

Yes. Since the implementation of IBMQJob changed noticeably, I've discarded most of my changes from the original PR but that's the only difference.

Does this solve #234?

Not yet. It contributes to that but it is not replacing the original IBMQJob suite and more work is needed in other parts of the library.

atilag
atilag previously approved these changes Jun 21, 2018
this_result = self._wait_for_job(timeout=timeout, wait=wait)
except TimeoutError as err:
# A timeout error retrieving the results does not imply the job
# is failing. The job can be still running.
Copy link
Member

Choose a reason for hiding this comment

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

Good point, but the Result has an ERROR status, so for the user something wrong happened with this Job. Should we state in any way, that this may not be a real Job error?... like having another status for "TIMEOUT" or something similar.

Copy link
Member

Choose a reason for hiding this comment

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

Let's mark this for future improvements... we need to merge this asap.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See #588 for the follow-up.

Copy link
Contributor

Choose a reason for hiding this comment

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

When job cancellation works on all IBM Q systems timeout could use that to cancel the job, which could be considered an error.

The test suite does not require network connection. It fakes the
QJOB object and the API behaviour.
Copy link
Member

@diego-plan9 diego-plan9 left a comment

Choose a reason for hiding this comment

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

Thanks everyone for the effort!

@diego-plan9 diego-plan9 merged commit 2cbbf78 into Qiskit:master Jun 21, 2018
@delapuente delapuente deleted the test-ibmqjob-in-isolation branch November 8, 2018 15:08
lia-approves pushed a commit to edasgupta/qiskit-terra that referenced this pull request Jul 30, 2019
* Adding test suite for testing IBMQJob in isolation.

The test suite does not require network connection. It fakes the
QJOB object and the API behaviour.

* Removing QuantumJob

* Adding expected failure when cancelling during initialization
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.

5 participants