DejaGnu: The GNU Testing Framework | ||
---|---|---|
<<< Previous | Getting DejaGnu up and running | Next >>> |
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.
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. |
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.
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:>' |
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.
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:
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 |
Not yet written, as I have problem getting libc6-dev-powerpc to work. Probably I first have to build my cross compiler.
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 WindowsNT) 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 |