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

Improved SRA tests, corrected error message #638

Merged
merged 2 commits into from
Jul 29, 2016

Conversation

a-nikitiuk
Copy link
Contributor

@a-nikitiuk a-nikitiuk commented Jun 7, 2016

Description

These changes are intended to resolve most of previously reported SRA-related issues:

Checklist

  • Code compiles correctly
  • New tests covering changes and new functionality
  • All tests passing
  • Extended the README / documentation, if necessary
  • Is not backward compatible (breaks binary or source compatibility)

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.006%) to 68.053% when pulling 5d75514 on a-nikitiuk:sra-fixes into e38b849 on samtools:master.

@@ -61,7 +61,8 @@ public SRAFileReader(final SRAAccession acc) {
this.acc = acc;

if (!acc.isValid()) {
throw new IllegalArgumentException("Invalid SRA accession was passed to SRA reader: " + acc);
throw new IllegalArgumentException("SRAFileReader: cannot resolve SRA accession '" + acc + "'\n" +
Copy link
Contributor

Choose a reason for hiding this comment

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

isn't it clear at some point in the code that a connection has been established but that the accession is bad? why not inform the user?

@yfarjoun
Copy link
Contributor

@a-nikitiuk back to you. only one comment really: can you not distinguish between a bad connection and a bad accesssion string? It seems that some part of the code must know, so perhaps you can give an return code to isValid() that will be more than a boolean and work with that. The problem is that if the accession becomes "bad" because of code change we will never find out because we will skip the test.

@a-nikitiuk
Copy link
Contributor Author

Unfortunately, it is not possible in current version of NGS API. We are working on improvement, but that is not an easy and quick fix.

@yfarjoun
Copy link
Contributor

In that case @a-nikitiuk I think it would be better to test connectivity with a single @BeforeGroup using an accession that is bound to exist (perhaps you have some sort of testing object that can be used for that?) and then remove the @BeforeTest so that each of the individual tests will fail if their accession is not valid. while this is fragile wrt losing connectivity in the middle of running the tests, it doesn't require a separate check that all the accessions are valid.

@yfarjoun
Copy link
Contributor

@a-nikitiuk This needs to be rebased, and also did you have time to think about my suggestion of using @BeforeGroup rather than @BeforeTest ?

@yfarjoun
Copy link
Contributor

@a-nikitiuk will you have time to rebase and replace @BeforeMethod with @BeforeTest ?

We would love to have these changes....

@a-nikitiuk
Copy link
Contributor Author

Yeah, will do that. Sorry, did not have much time lately

@a-nikitiuk
Copy link
Contributor Author

Rebased and added @BeforeGroups method

@coveralls
Copy link

Coverage Status

Coverage increased (+0.006%) to 68.416% when pulling 2fcb11c on a-nikitiuk:sra-fixes into e7c7bf6 on samtools:master.

}

if (accession != null &&
accession.matches(SRAAccession.REMOTE_ACCESSION_PATTERN) && !canResolveNetworkAccession) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Since you are no longer asking to connect for every accession, wouldn't it be better to remove the first condition, so that if someone puts in a non-matching accession to a new test, it 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.

If someone puts a non-matching accession, then this code will do nothing. However, it detects remote accessions from its first argument, and if remote accession is detected and canResolveNetworkAccession is false then it skips the test.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, OK. can you then simply change the text in the Exception to:

  1. note the accession that cannot be resolved, and
  2. change "SRA accession" with "remote SRA accession"?

@yfarjoun
Copy link
Contributor

@a-nikitiuk are you planing to make these changes, or should I do them?

@a-nikitiuk
Copy link
Contributor Author

You can do them if you would like to. Or I will try to find time for that today-tomorrow

@yfarjoun
Copy link
Contributor

OK. I'll leave it to you then! thanks!

On Tue, Jul 26, 2016 at 2:20 PM, a-nikitiuk [email protected]
wrote:

You can do them if you would like to. Or I will try to find time for that
today-tomorrow


You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#638 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACnk0o2DcApbHYeMg6Q2-lK8vfCBKtdtks5qZk_0gaJpZM4Iwd2p
.

@a-nikitiuk
Copy link
Contributor Author

Done

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.006%) to 68.45% when pulling b780a55 on a-nikitiuk:sra-fixes into 87b1e87 on samtools:master.

@yfarjoun
Copy link
Contributor

thanks! 👍

jamesemery pushed a commit to jamesemery/htsjdk that referenced this pull request Sep 1, 2016
* Fixed SRA tests issues, corrected error message

* Network related tests now depend on ability to resolve single SRR000123 accession
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.

3 participants