Fix for converter tests

[bernt-matthias]

First I tried to be as unintrusive as possible, i.e. to keep assertions for the zipped output. But finally I went for having only tests wrt the decompressed output (i.e. with decompress="true").

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[mvdbeek]

Thanks a lot!

[mvdbeek]

Can you also fix the vcf_to_vcf_bgzip test ? And do we know why the test outputs are suddenly larger ?

[bernt-matthias]

Can you also fix the vcf_to_vcf_bgzip test ?

Sure

And do we know why the test outputs are suddenly larger ?

I'm also wondering. I thought that it's a conincidence of #13411 and
#15085 .. but this is to long ago I guess.

Since we use containerized tests and the containers were not updated recently (in the last months) also this can't be the reason.

Did we change something in the testing recently?

[mvdbeek]

Can you please make sure the converters run and that the output is compressed ?

[bernt-matthias]

Ahh... the converter tests use planemo .. so they use the available planemo and the available packages .. and the planemo supporting 23.1 was just release on December 6.

Edit: so its #15085 .. delayed by the release of planemo.

[bernt-matthias]

Checked my local planemo test for the vcf_to_vcf_bgzip_converter. The test ran exactly two tools: upload and the converter and the output file is Blocked GNU Zip Format (BGZF; gzip compatible), block length 688

[mvdbeek]

Can we instead assert the size against the API value for file_size ? I don't know if comparing against the decompressed size is really all that intuitive ? I don't like the idea of "breaking" tests this way.

[bernt-matthias]

Can we instead assert the size against the API value for file_size ?

Sure possible. We can even do both (as I did in the first commit).

But I would suggest to add a delta, since in my experience zip files tend to have different file sizes over time (probably because the compression algorithm changes). Do you have a suggestion? 10% of the size?

[mvdbeek]

ok, I guess we just gotta live with this.

[bernt-matthias]

ok, I guess we just gotta live with this.

Not necessarily, was just busy with the linters PR.

How about testing with <has_size max="DECOMPRESSED_SIZE-1"/>` .. would be a very basic test for a compression (which would fail only for a single test of these tools where the decompressed file size is very small).

[mvdbeek]

I don't care about the tests here, I care about breaking tool tests we don't control.