Export Test Report as PDF and Preserve File Extensions

[RikkeVestesen]

Hi Costas

When downloading test data, we need the test report to be exported as a PDF rather than XML.

We also need the original file extensions to be included for all downloaded files, so they can be identified and opened correctly. Now, the downloaded files do not include file extensions, which means we are unable to open them.

Would it be possible to update the download functionality accordingly?

[costas80]

Hey @RikkeVestesen.

To understand better, I'm guessing you are referring to the Download test data option right?

If this is the case ...

When downloading test data, we need the test report to be exported as a PDF rather than XML.

Well, the XML report that is included in this archive is really meant as an index of sorts to understand the purpose of each file. If you want to get the PDF equivalent, you could use the Download report option. Alternatively we could generate a variant of the same PDF report and include it alongside the XML one, in which the reference file UUIDs are displayed instead of the "File content" you see when downloading the regular PDF report. Would this cover you?

We also need the original file extensions to be included for all downloaded files, so they can be identified and opened correctly. Now, the downloaded files do not include file extensions, which means we are unable to open them.

I understand this point but this is not so straightforward. The files included in the archive represent anything that is too large to include as-is in the reports. In simple cases this could be a user-uploaded file where we could record the name and reuse it, but in other cases this could be generated/processed/received text/binary content that is simply too large to include as-is. Even cases that seem obvious are not safely so - for example you use an XML file imported from a test suite resource, but then you process this with XSLT to give you HTML, RDF or JSON.

Now what we could benefit from is that this data download is an admin-only operation so we can make it a bit more heavy to increase its ease-of-use. We can fully ignore the test case definition, and simply take each of these files and use sampling/detection logic to try and figure out their content type. For most binary types this can be identified through magic bytes, whereas for text content we could try to match common formats with a generic "text/plain" fallback. What I'm getting at - that I would like to confirm with you - is that the file extensions would be determined as follows:

• A best-effort estimation of text files to identify common syntaxes (e.g. XML, JSON) and result in their extensions (.xml, .json etc.).
• A fallback for any text files that were not covered by the previous step of simply plain text (.txt).
• A best-effort estimation for binary files to detect at least image types and other common binary formats (anything with magic bytes).
• A fallback for any binary files not covered by the previous step of simply no extension (these cases should be exceptional).

We then will simply keep the UUID-based naming of files that we currently have, but just add to them the resolved extensions for the resulting download archive.

Would this work for you?

[costas80]

Adding an extra precision for this feature: the naming of files will also replace the current UUIDs to use more user-friendly information (e.g. the internal step identifiers "1", "1.1" etc.). This will be applied both to the files in the archive as well as to the references included in the accompanying XML and PDF reports.