DejaGnu: The GNU Testing Framework
<<< Previous | Getting DejaGnu up and running | Next >>>

# A first remote test

Testing remote targets is a lot trickier especially if you are using an embedded target which has no built in support for things like a compiler, ftp server or a Bash-shell. Before you can test calc on a remote target you have to acquire a few basics skills.

## Setup telnet to your own host

The easiest remote host is usually the host you are working on. In this example we will use telnet to login in your own workstation. For security reason you should never have a telnet deamon running on machine connected on the internet, as password and usernames are transmitted in clear text. We assume you know how to setup your machine for a telnet daemon.

Next try whether you may login in your own host by issuing the command “telnet localhost.1”. In order to be able to distinguish between a normal session an a telnet login add the following lines to /home/dgt/.bashrc.

    if [ "$REMOTEHOST" ]
    then
       PS1='remote:\w\$ '
    fi

Now on the machine a “remote” login looks like this:

Example 11. Sample log of a telnet login to localhost

    dgt:~/dejagnu.test$ telnet localhost
    Trying 127.0.0.1...
    Connected to 127.0.0.1.
    Escape character is '^]'.
    Debian GNU/Linux testing/unstable Linux
    K6Linux login: dgt
    Password:
    Last login: Sun Nov 25 22:46:34 2001 from localhost on pts/4
    Linux K6Linux 2.4.14 #1 Fre Nov 16 19:28:25 CET 2001 i586 unknown
    No mail.
    remote:~$ exit
    logout
    Connection closed by foreign host.

## A test case for login via telnet

In order to define a correct setup we have add a line containing “set target unix” either to ~/.dejagnurc or to ~/my_dejagnu.exp. In ~/boards/standard.exp add the following four lines to define a few patterns for the DejaGnu telnet login procedure.

Example 12. Defining a remote target board

    set_board_info shell_prompt    "remote:"
    set_board_info telnet_username "dgt"
    set_board_info telnet_password "top_secret"
    set_board_info hostname        "localhost"

As DejaGnu will be parsing the telnet session output for some well known pattern the output there are a lot of things that can go wrong. If you have any problems verify your setup:

- Is `/etc/motd` empty?

- Is `/etc/issue.net` empty?

- Exists a empty `~/.hushlogin`?

- The LANG environment variable must be either empty or set to “C”.

To test the login via telnet write a sample test case. Create the file ~/dejagnu.test/testsuite/calc.test/remote_echo.exp and add the following few lines:

Example 13. DejaGnu script for logging in into a remote target

    puts "this is remote_echo.exp target for $target "
    target_info $target
    #set verbose 9
    set shell_id [remote_open $target]
    set test "Remote login to $target"
    #set verbose 0
    puts "Spawn id for remote shell is $shell_id"
    if { $shell_id > 0 } {
       pass "$test"
    } else {
       fail "Remote open to $target"
    }

In the runtest output you should find something like:

    Running ./testsuite/calc.test/local_echo.exp ...
    Running ./testsuite/calc.test/remote_echoo.exp ...
    this is remote_echo.exp target is unix
    Spawn id for remote shell is exp7

Have again a look at calc.log to get a feeling how DejaGnu and expect parse the input.

## Remote testing “Hello world”

Next you will transform the above “hello world” example to its remote equivalent. This can be done by adding the following lines to our file remote_echo.exp.

Example 14. A first (local) remote "Hello world" test

    set test "Remote_send Hello World"
    set status [remote_send $target "echo \"Hello\" \"World\"\n" ]
    pass "$test"
    set test "Remote_expect Hello World"
    remote_expect $target 5 {
       -re "Hello World"  { pass "$test" }
    }

Call make check. The output should contain “# of expected passes 9” and “# of unexcpected failures 1”.

Have a look at the procedures in /usr/share/dejagnu/remote.exp to have an overview of the offered procedures and their features.

Now setup a real target. In the following example we assume as target a PowerBook running Debian. As above add a test user "dgt", install telnet and FTP servers. In order to distinguish it from the host add the line

    PS1='test:>'

to /home/dgt/.bash_profile. Also add a corresponding entry "powerbook" to /etc/hosts and verify that you are able to ping, telnet and ftp to the target "powerbook".

In order to let runtest run its test on the "powerbook" target change the following lines in ~/boards/standard.exp:

Example 15. Board definition for a remote target

    set_board_info protocol        "telnet"
    set_board_info telnet_username "dgt"
    set_board_info telnet_password "top_secret"
    set_board_info shell_prompt    "test:> "
    set_board_info hostname        "powerbook"

Now call runtest again with the same arguments and verify whether all went okay by taking a close look at calc.log.

## Transferring files from/to the target

A simple procedure like this will do the job for you:

Example 16. Test script to transfer a file to a remote target

    set test "Remote_download"
    puts "Running Remote_download"
    # set verbose 9
    set remfile /home/dgt/dejagnu2

    set status [remote_download $target /home/dgt/.dejagnurc $remfile]
    if { "$status" == "" } {
         fail "Remote download to $remfile on $target"
    } else {
       pass "$test"
    }

    puts "status of remote_download ist $status"
    # set verbose 0

After running runtest again, check whether the file dejagnu2 exists on the target. This example will only work if the rcp command works with your target. If you have a working FTP-server on the target you can use it by adding the following lines to ~/boards/standard.exp:

Example 17. Defining a board to use FTP as file transport

    set_board_info file_transfer   "ftp"
    set_board_info ftp_username    "dgt"
    set_board_info ftp_password    "1234"

## Preparing for crosscompilation

For crosscompiling you need working binutils, gcc and a base library like libc or glib for your target. It is beyond the scope of this document to describe how to get it working. The following examples assume a cross compiler for PowerPC which is called linux-powerpc-gcc.

Add AC_CANONICAL_TARGET in dejagnu.test/configure.in at the following location. Copy config.guess from /usr/share/automake to dejagnu.test.

    AM_CONFIG_HEADER(calc.h)
    AC_CANONICAL_TARGET([])
    AM_INIT_AUTOMAKE(calc, 1.1)

You need to run automake 2.5 or later. Depending on your installation calling autoconf2.5 instead of autoconf is not needed. The sequence to regenerate all files is:

Example 18. Using autotools for cross development

    $ autoconf2.5
    $ autoheader
    $ automake
    $ ./configure --host=powerpc-linux --target=powerpc-linux
    configure: WARNING: If you wanted to set the --build type, don't use --host.
        If a cross compiler is detected then cross compile mode will be used.
    checking build system type... ./config.guess: ./config.guess: No such file or directory
    configure: error: cannot guess build type; you must specify one
    $ cp /usr/share/automake/config.guess .
    $ ./configure --host=powerpc-linux --target=powerpc-linux
    configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used. \
    checking build system type... i586-pc-linux-gnu
    checking host system type... powerpc-unknown-linux-gnu
    <...>
    checking whether we are cross compiling... yes
    <...>
    Configuration:
    Source code location: .
    C Compiler: powerpc-linux-gcc
    C Compiler flags: -g -O2

Everything should be ready to recompile for the target:

    $ make
    powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c calc.c
    powerpc-linux-gcc -g -O2 -o calc calc.o

## Remote testing of calc

Not yet written, as I have problem getting libc6-dev-powerpc to work. Probably I first have to build my cross compiler.

## Using Windows as host and vxWorks as target

A more thorough walk-through will be written in a few weeks.

In order to test the vxWorks as a target I changed boards/standards.exp to reflect my settings (IP, username, password). Then I reconfigured vxWorks to include a FTP and telnet server (using the same username/password combination ad in boards/standard.exp).

With this setup and some minor modification (e.g. replacing echo by printf) in my test cases I could test my vxWorks system. It sure does not seem to be a correct setup by DejaGnu standard. For instance, it still loading /usr/share/dejagnu/baseboards/unix.exp instead of vxWorks. In any case I found that (at least under Windows) I did not find out how the command line would let me override settings in my personal config files.

<<< Previous | Home | Next >>>
Our first automated tests | Up | Running Tests