Hi Harish, > while learning about the autopkgtest, I came across some questions and would like to hear your opinion before I proceed: > 1. Do I really have to run the bitseq commands to produce the .fasta file for testing, or is there any other way to produce? If the package does not provide any .fasta file, and if you don't have any way to generate one, there are still several options. I tend to favor repurposing example data from other packages. To find the sort of file that I am after, I extensively use apt-file, e.g. for fasta files: $ apt-file search --regex '.*\.fasta$' | less There are plenty of options available in various packages already wrapped by the Debian Med team. > 2.How to create or verify the checksum of the test output, where we get the real checksum of package to match the actual checksum and the .fasta checksum? Hmn, good question, I fear by not being of the field that I can't know for sure that any test suite I invent is the correct result. However, I'd tend to reasonably assume that some result that is not a full array of zeroes, or a series of error messages, would be a reasonably good result. If despite the seemingly correct results, the program is actually inoperative, then I think this is one of those cases where we cannot do much, except be responsive to bugs opened in the BTS by our end users. Note that sometimes, some processing steps may not be repeatable, for example when running heuristic processing steps involving data points derived from random sources; in such situation, recording results control sums won't work. I don't know if this is the case with bitseq tools. > 3.I noticed that there's no examples dir in /usr/share/doc/pkg/. Should we add one before run the test? I don't see bitseq providing examples. Personally, I would refrain from inventing my own examples, and prefer to refer to other files from other packages, see my answer to your first question. That being said, other contributors managed to locate supplemental data to feed to their autopkgtests. > 4. BitSeq's guide for use demonstrates an actual example of creating ensembleGenes.fasta. Should I repeat that entire process during the test, or is it alright to cut corners for the sake of speed? I would lean in favor of the test coverage over the run time. I'd tend to assume upstream's documentation would show a workflow representative of a regular user workload, thus you might want to stick to it as much as possible. Of course, if a step is unrelated to running bitseq commands and takes a lot of time compared to running them, then it can be reconsidered. In extreme situations, long run time may cause debci runners to timeout, in which case it will become necessary to indeed take shortcuts in the test suite, but this is the exception, not the rule. Does this answer your questions? Have a nice day, :) -- .''`. Étienne Mollier <emollier@debian.org> : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/6, please excuse my verbosity `- on air: Mozart - Concerto pour piano et orch n°21
Attachment:
signature.asc
Description: PGP signature