Re: using package tests
It doesn't sound like a good idea to change debian/tests/control and
alter the Test-Command in it. Wouldn't it be better to provide test
script in debian/tests? i.e. triggered by a Tests: entry in
On 2020-04-21 04:00, Mark Olesen wrote:
Looks to be successful - thanks Drew.
Now generating the tests as part of the configuration process. At that
point I know what the location of the target executable/wrapper will
be and can use that to repopulate the test/control with a list of
"Test-Command" based on an input list of test tutorials.
Modified the target wrapper to include a '-test-tutorial' flag to
handle the tests via the installed backend.
On 2020-04-20 05:20, Drew Parsons wrote:
On 2020-04-20 05:43, Mark Olesen wrote:
That is actually fairly easy!
When running the tests, is there a standard way to obtain information
about what is being tested, or to pass in such information?
To explain, suppose that I define a simple runner script called
'AutoTest' that would be part of the "-tutorials" subpackage, since
those are the best ones for testing if the installation is
This means that in my source tree I would have something like this,
Do I hard-code the /installed/path/tutorials into the tests/control ?
or should these be the ones local to the build directory (ie,
I checked the env, but the only seeming relevant entry was
AUTOPKGTEST_ARTIFACTS, which seems to be an empty directory.
Superficially it runs from the top level source dir. Not the build
dir, never the build dir. But "build" in your path here is a parent
dir I think, so your toplevel is /some/build/path/. Then you can use
relative paths from there to reference the files in the source tree.
But under the hood, the source dir actually gets copied to a tmp dir
(so any files generated by tests will not end up in your original
You get a clean tmp dir $AUTOPKGTEST_TMP that you can manipulate in
your debian/tests scripts.
Since the point of the exercise is to check that the installed package
works, not the source that it was made from as such, it's not a bad
idea to use installed files rather than files in the source tree. So
your debian/tests script can run your installed
/installed/path/tutorials/AutoTest, or copy it to $AUTOPKGTEST_TMP and
then run it.
When specifying the tests/control, I need them to depend both on the
first binary package being built as well as the tutorials. So a
like this is what I want:
Depends: @, @-tutorials
Since debci uses a minimal clean chroot, so all needed packages will
need to be specified. The @ is just short hand for lazy people
(useful if a large collection of packages needs to be specified).
On 2020-04-18 04:43, Drew Parsons wrote:
debci tests are run in a chroot.
But for testing locally (i.e. simply running the tests), you can
autopkgtest -B -- null