Re: Bug#879619: Autopkgtest for ncbi-tools6
Dear Liubov,
On Sat, Mar 24, 2018 at 02:35:41PM +0000, Liubov Chuprikova wrote:
>
> I have started to work on writing tests for *ncbi-tools6*, which is the
> source for multiple binary packages.
Yes. Its tough that you want to tackle this more complex package which
is definitely very valuable since its a frequently used package.
> Some of them contain shared libraries,
> others are with data files and only two contain executables (
> *ncbi-tools-bin* and *ncbi-**tools-x11*). Is there a way to test graphical
> applications in *ncbi-tools-x11?
I once had the idea in the figtree package to use xvfb-run[1]. It was
not really successful and most probably the answer is: No, there is no
sensible way to test X applications right now.
> *Should I ignore non-executable binary packages?
Yes. Even if the wording is not fully correct. When autopkgtests are
run all binary packages are installed besides the source package on the
testing machine. Thus the test is working on all binary packages in
principle - but we are running the command line executables in the test
suite. The special way I prefer to provide the test script also as
user installable example in /usr/share/doc/<packagename>/run-unit-test
is strictly speaking not what autopkgtest is doing - it runs any
script that is specified in PKGSOURCE/debian/tests/control (= in the
unpackaged source package).
But if we stick to the user executable example this should be installed
into the package containig the command line executables binary package.
> Meanwhile, I have pushed my first efforts to check some of the
> functionality inside *ncbi-tools-**bin *(commit
> <https://salsa.debian.org/med-team/ncbi-tools6/commit/f3a5fe13a410a0b42cf4bbe4e128735e3c7e0348>).
> At the moment, the commands in the test run one by one and the test exits
> on the first fail. I thought it would be better if the test gathers exit
> statuses of each command and returns only global exit status instead and
> maybe some summary of which commands fail? I could implement this idea if
> you don't think it is too much.
Well, I'm fine if you think this is better. But we need to look for
errors whereever it happens and I do not consider it very important to
do the sophisticated design you are proposing. So it does not harm but
I think it is more important to add the way you obtained the data to
d/control (as in the previous example).
> I haven't changed the copyright yet because I am likely to add more
> additional test files later.
>From my personal point of view I would add a copyright notice right
when injecting additional files that need to be mentioned. Its just
that the memory is fresh what was done to get the file.
> However, I always doubt that I don't see
> something else that I need to pay attention to. I'll be happy to receive
> any recommendations from you!
Without having built the package and tested the script it looks sensible
to me as it is. I'll start a build and will give further remarks if
needed.
Thanks for your work on this
Andreas.
[1] https://salsa.debian.org/med-team/figtree/blob/master/debian/tests/run-unit-test
--
http://fam-tille.de
Reply to: