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