[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 debian/test/control.

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:
Hi Drew,

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 successful.

This means that in my source tree I would have something like this,


but also


Do I hard-code the /installed/path/tutorials into the tests/control ?
or should these be the ones local to the build directory (ie,
/some/build/path/tutorials/AutoTest) ?

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 source dir). 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 syntax
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 invoke

   autopkgtest -B -- null

Reply to: