[Bash-completion-devel] file inclusions in test suite

Freddy Vulto fvulto at gmail.com
Mon Jan 4 19:49:03 UTC 2010


On 100103 13:23, Guillaume Rousse wrote:
> I recently commited autotools-integration of test suite. It works, but
> only in classical usage scenarion, meaning running ./configure inside
> the source directory. Using vbuild (running configure from another
> directory), as in the 'make distcheck' scenario, doesn't work, because
> all inclusions path are relative to current working directory.
> 
> For instance, file 'completion/ssh.exp' include
> 'lib/completions/ssh.exp'. If you're executing the test from anywhere
> else as 'test' directory, it does't work.
> 
> test
> ├── completion
> │   └── ssh.exp
> └── lib
>     └── completions
>         └── ssh.exp
> 
> Is there a way to make those inclusions relative to either including
> file location, or to a variable sourcedir instead ?

I've looked in DejaGnu's `runtest' and saw they're their own method called
`load_file' instead of `source'.  Maybe we can use this as well:

   load_file $libdir/completions/ssh.exp

But how are the tests executed from within autotools, via runtest,
runCompletion or run, and can't these be made to do a change dir to the `test'
directory before executing tests?  Anyway, no objections to replace `source ..'
with `load_file $libdir/..' if this makes autotools work.

And - forgive me if a dumb question - what's the benefit/typical-usage, once
having autotools-integration of the test suite?

> Also, why do we need to move actual completion test to
> lib/completion/ssh.exp, instead of leaving it in completion/ssh.exp ?
> I've had a quick look, it doesn't seems to be included from anywhere else.

The separation originates from bash-completion-lib where completions are tested
twice; once before dynamic loading and a second time after: it proved to be
useful to have the completions in a separate file so the completions can be
tested twice easily. 

The effect is that tests in `test/completion' contain tests for the completion
*loading* (but also ignite the testing of the real completions), whereas
`test/lib/completions' contain tests for the actual completions.

Although the double inclusing isn't used right now, the idea was to keep this
structure intact, since the goal is to copy the dynamic loading of
bash-completion-lib to bash-completion in the near future.  For example, this
is `completion/find.exp' from bash-completion-lib:

---8<-------------------------------------------------------------------
set test "Completion via comp_load() should be installed"
set cmd "complete -p find"
send "$cmd\r"
expect {
    -re "^$cmd\r\ncomplete -o filenames -F comp_load find\r\n/@$" { pass "$test" }
    -re /@ { fail "$test at prompt" }
}; # expect


source "lib/completions/find.exp"


set test "Completion via _find() should be installed"
set cmd "complete -p find"
send "$cmd\r"
expect {
    -re "^$cmd\r\ncomplete -o filenames -F _find find\r\n/@$" { pass "$test" }
    -re /@ { fail "$test at prompt" }
}; # expect


source "lib/completions/find.exp"
---8<-------------------------------------------------------------------


Regards,

Freddy Vulto
http://fvue.nl



More information about the Bash-completion-devel mailing list