On Friday 11 April, 2025 at 03:08:05 am IST, Étienne Mollier <emollier@debian.org> wrote:
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