ATF-devel archive

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

Re: ATF confusion with improperly terminated script



On Sun, Feb 06, 2011 at 11:00:59AM -0800, Garrett Cooper wrote:
> On Sun, Feb 6, 2011 at 8:00 AM, Julio Merino 
> <jmmv%homeworld.netbsd.org@localhost> wrote:
> > On Sun, Feb 06, 2011 at 05:53:54AM -0800, Garrett Cooper wrote:
> >> Hi again Julio, et all,
> >> ? ? Until one runs set -x in the script below, it isn't apparent why
> >> the script was failing. Is this issue going to be fixed in the future
> >> with kyua?
> >
> > Error reporting in atf-run is weak. ?I have filed issue 13 in Kyua to
> > ensure this is not forgotten:
> >
> > http://code.google.com/p/kyua/issues/detail?id=13
> >
> > Is this lacking any detail?
> 
> I think that captures the bulk majority of my concerns, but there's
> another one I'm currently working through to try and understand why
> atf-sh isn't properly running testcases that *should* (in theory) work
> as the shell code is sane (just a bit convoluted because I'm trying to
> integrate the /bin/sh testcases from FreeBSD without converting or
> generating them all beforehand).
> 
> The result of the integration effort attempt is below and I can post
> the error log up on pastebin if desired (but before that it would be
> nice if there's a variable I could pass to atf-run to debug what's
> happening exactly from ATF's perspective when executing a testcase).

Ah, yes.  ATF does not have such feature at the moment.  That is something
I wanted to address in Kyua but have kept forgetting so far.  I have
filed issue 14 to keep track of this:

http://code.google.com/p/kyua/issues/detail?id=14

That said, atf-run should not be causing any issues here.  Your problems
most likely come from atf-sh; while not particularly nice, you could add
debugging/tracing commands to libatf-sh.subr.

> #!/usr/bin/env atf-sh

The way we do this in NetBSD is through some build magic that adds the
shebang header and makes it point to the exact atf-sh binary that ships
with the system.  Dunno if it is a good idea to make it rely on the path.

> # $FreeBSD$
> 
> export SH=${SH:=/bin/sh}
> 
> do_test() {
>         local atf_args expected_exit_status testcase_path testcase_prefix
> 
>         testcase_path=$1

If you need access to data files that live in the same directory as the test
program, you should query $(atf_get_srcdir).

>         expected_exit_status=${testcase_path##*.}
>         testcase_prefix=${testcase_path%.*}
> 
>         atf_args="-s exit:${expected_exit_status}"
> 
>         for i in e,stderr o,stdout; do
>                 output="${testcase_prefix}.${i##*,}"
>                 if [ -f "$output" ]; then
>                         atf_args="${atf_args} -${i%,*} '$output'"
>                 fi
>         done
> 
>         echo "INFO: atf_args: $atf_args, expected_exit_status:
> $expected_exit_status, testcase_path: $testcase_path, testcase_prefix:
> $testcase_prefix" >&2
> 
>         atf_check ${atf_args} ${SH} ${testcase_path}
> }
> 
> set -x
> 
> atf_init_test_cases() {
>         local testcase testcase_path
> 
>         for testcase_path in $(find -Es . -regex ".*\.[0-9]+"); do
> 
>                 testcase=$(echo "$testcase_path" | sed -e 's,^./,,g'
> -e 's,/,_,g' -e 's,\.,__,g' -e 's,-,____,g')
> 
>                 atf_test_case "test__$testcase"
>                 # XXX: would be nice if this was more descriptive,
> i.e. maybe comments
>                 # in the header, or a custom description file.
>                 eval "test__${testcase}_head() { atf_set 'descr'
> '$testcase testcase'; }"

If you feel that the descr is redundant, you don't need to set it.  I would
just skip this.  (And recently, I am personally skipping pretty much all
descriptions in favor of providing descriptive test case names.  I find
myself introducing less typos and inconsistencies this way.)

>                 eval "test__${testcase}_body() { do_test '$testcase_path'; }"
> 
>                 atf_add_test_case "test__$testcase"
> 
>         done
> }

Ouch; the code is indeed a bit convoluted!  I would suggest to start simple:
avoid all the logic to "autogenerate" the tests.  Define a single one by
hand to ensure there is no eval nastiness.  Also, run one particular test
without atf-run so that you can gain access to any generated temporary
files, etc.

What I mean is:

$ mkdir tmp
$ cd tmp
$ ../my_test_program the_test_case
$ ls
... ah ha!  the temporary files for the test program are here ...

-- 
Julio Merino


Home | Main Index | Thread Index | Old Index