PROJECT STAGE 2 - DejaGNU Testing Framework

Introduction to DejaGnu Testing Framework



What is DejaGnu?

In the world of software development, testing is a critical phase that ensures the quality and reliability of software before it reaches the end user. DejaGnu is a framework designed to facilitate the testing of software applications, providing developers with a robust environment for running tests across various platforms. Built on top of the Expect programming language, which in turn utilizes Tcl (Tool Command Language), DejaGnu offers a powerful and flexible way to automate the execution of test suites and manage test results.

The Origins and Purpose of DejaGnu

Developed initially by Rob Savoye and others at Cygnus Solutions, DejaGnu has grown to become a favored tool for testing by many in the open-source community. Its primary goal is to provide a consistent interface for writing and running tests, making it easier for developers to test their applications on different hosts and target platforms. This cross-platform capability is particularly valuable in environments where software needs to run reliably on multiple operating systems or hardware configurations.

How DejaGnu Works

DejaGnu operates by executing test scripts written for specific software components or applications. These scripts, typically written in Tcl using the Expect commands, define a series of tests, the expected outcomes, and the criteria for success. DejaGnu then runs these scripts, interacts with the applications being tested as needed (simulating user input, checking output, etc.), and reports the results.

One of the key features of DejaGnu is its ability to simulate user interactions with a program, thanks to Expect. This makes it particularly effective for testing command-line tools, interactive applications, and even networked applications requiring specific inputs or responses.

Setting Up DejaGnu in my local PC

Referring to official documentation of DejaGNU,
I had the option to install dejaGnu on my local Mac by cloning the git URL
$ git clone git://git.sv.gnu.org/dejagnu.git

As I already have homebrew setup on my mac I directly installed it with `brew install dejgnu`


Writing my first C Program and testing it

// hello.c #include <stdio.h> int main() { printf("Hello, World!\n"); return 0; }

After compiling the above program. We should get the expected output:


Testing the above with DejaGnu

# hello.exp set test_name "Hello World Test" set srcdir . set tool hello proc pass {msg} { puts "PASS: $msg" } proc fail {msg} { puts "FAIL: $msg" } # Test spawn ./hello expect { "Hello, World!" { pass "Output as expected" } default { fail "Unexpected output" } }

The .exp extension above is helping dejagnu specify that this is a test case after executing the tests using runtest -srcdir . command we got that test passed output as expected:


DejaGnu in relation to GCC

DejaGnu uses `.dg` files as part of its testing framework, particularly when working with GCC (GNU Compiler Collection) test suites. These `.dg` files are used to write test cases for compiler testing, allowing you to specify source code to compile, options to pass to the compiler, and the expected results or outputs from the compilation process. The `.dg` file format is a way to describe tests in a structured manner that DejaGnu can understand and execute.

Understanding .dg Files

A `.dg` file typically contains a series of Tcl commands and DejaGnu directives that define how a test should be run, what compiler options to use, and how to interpret the results. These files are part of the broader DejaGnu testing framework, which is built on top of Expect and Tcl, and they are specifically designed to test compilers like GCC.

Basic Structure of a .dg File

Here's a simplified example of what a .dg file might look like:

# Example.dg
# Test for successful compilation
# dg-do compile
# dg-options "-O2"

/* Test code */
int main() {
  return 0;
}

In this example, the comments starting with `#` are special directives understood by DejaGnu:

- `# dg-do compile` tells DejaGnu that this test involves compiling the source code.
- `# dg-options "-O2"` specifies that the `-O2` optimization flag should be passed to the compiler.

The C code following these directives is the source code to be compiled as part of the test.

How to Use .dg Files

To use `.dg` files in your testing, you typically place them in a directory structure organized according to the tests' purposes and then invoke DejaGnu with the `runtest` command, specifying any necessary options and the directory containing your `.dg` files. DejaGnu processes these files, compiles the specified code with the given options, and checks the results against the expected outcomes defined in the `.dg` files.

Comments

Post a Comment

Popular posts from this blog

PROJECT STAGE 1

Getting started:  -Obtain the source code for the current development version of GCC from the Git repository. git clone git://gcc.gnu.org/git/gcc.git  cd gcc   - To build GCC outside of the source tree to keep things clean, build directory was created by following command: mkdir build Configure the build for each of two environments. It sets up the build to create a compiler. -Build GCC. Run make to start the compilation process. Task 1  Prune Cloned Functions (a) Specific, Relevant Sections of the GCC Code Base The relevant sections of the GCC codebase to prune cloned functions can be found in the files where function versioning and cloning are handled. This includes: gcc/function.c for managing functions. gcc/config/aarch64/aarch64.c for configuring AArch64. gcc/tree-vect-loop.c, or similar files, for vectorization and cloning logic. (b) Work Detail It is involved in the identification of cloned functions in AFMV, which do not offer enough improvements in performan...
Read more

64-Bit Assembly Language Lab

After successfully setting up the servers, namely  AArch64 and x86_64.   Step 1 involved reviewing AArch64 assembly code, including examining the code with objdump to understand the correspondence between source code and machine instructions Step 2 introduced a basic loop structure in AArch64 assembly, looping from 0 to 9 using register x19 as the index counter. The code provided a skeleton loop structure but did not perform any meaningful actions within the loop. .text .globl _start min = 0 /* starting value for the loop index; **note that this is a symbol (constant)**, not a variable */ max = 10 /* loop exits when the index hits this number (loop condition is i<max) */ _start: mov x19, min loop: /* ... body of the loop ... do something useful here ... */ add x19, x19, 1 cmp x19, max b.ne loop mov x0, 0 /* status -> 0 */ mov x8, 93 /* ...
Read more

Assembly language code lab 2

Image
  Lab 2 adding calculator  About:  The Adding Calculator program is designed for a computer system with specific memory locations and routines. The program prompts the user to enter two decimal numbers, performs addition, and displays the sum. Code: ; Adding Calculator ; ROM routine entry points define SCINIT $ff81 ; initialize/clear screen define CHRIN $ffcf ; input character from keyboard define CHROUT $ffd2 ; output character to screen ; zeropage variables define PRINT_PTR $10 define PRINT_PTR_H $11 define firstInput $14 define secInput $15 ; absolute variables define GETNUM_1 $0080 define GETNUM_2 $0081 define ENTER $0d ; for the ENTER key define BACKSPACE $08 ; for the BACKSPACE key ; -------------------------------------------------------- ; Main loop jsr SCINIT ; initialize/clean screen main: ; get first input' ldy #$00 jsr firstIn...
Read more