Difference between revisions of "Delta debugging testcases"

From CDOT Wiki
Jump to: navigation, search
(Initial edit)
 
(Test Cases Design)
Line 5: Line 5:
 
== Test Cases Design ==
 
== Test Cases Design ==
  
 +
There are many elements involved in the test cases, though they are split into categories. Here are some of them.
  
 +
 +
=== Source Code ===
 +
* This is where the actual program to be tested resides. The program can be in any language, but has to be able to be compiled and executed in a given environment (i.e. for a C++ program, there should be a C++ compiler in the system or Cygwin environment).
 +
* It is suggested that this source code resides in a directory separated from the rest of the framework. The test will focus on that directory, and the framework should reside around it. Observe the following diagram:
 +
<pre>
 +
/home
 +
  +-- /tests
 +
    +-- /HelloWorld
 +
      +-- HelloWorld.c
 +
</pre>
 +
In this diagram, the framework should reside on the '''tests''' directory to allow it to wrap the source code.
 +
* The idea is that this source code used to pass a test, but no longer due to recent changes in the code. User should then back up the source code, set up the framework, and run the Delta Debugging Algorithm to find the last revision that passes the test.
 +
 +
 +
=== Build Script ===
 +
* This is a Perl file (.pl), and should be named accordingly (e.g. HelloBuild.pl, SudokuBuild.pl).
 +
* This file contains the script needed to properly build the source code. This script is located in the '''build()''' function, which will be called by the algorithm.
 +
* The separation of the build file from the rest of the code allows user to select and customize various build systems or compilers that exist in the market. Whether the source code requires certain compiler, or uses Makefile for the GNU Make, this file handles the customization.
  
 
== Test Cases ==
 
== Test Cases ==

Revision as of 17:22, 13 December 2006

Description

Richard Chu created the design of the test cases based on his understanding on the JUnit test-driven development environment. The idea is to set up a standard Design Pattern for future test cases that allow modification and flexibility. This pattern will, in turn, interact with the rest of the Delta Debugging Framework, but this relationship needs to be understood for the interaction to work well.

Test Cases Design

There are many elements involved in the test cases, though they are split into categories. Here are some of them.


Source Code

  • This is where the actual program to be tested resides. The program can be in any language, but has to be able to be compiled and executed in a given environment (i.e. for a C++ program, there should be a C++ compiler in the system or Cygwin environment).
  • It is suggested that this source code resides in a directory separated from the rest of the framework. The test will focus on that directory, and the framework should reside around it. Observe the following diagram:
 /home
   +-- /tests
     +-- /HelloWorld
       +-- HelloWorld.c

In this diagram, the framework should reside on the tests directory to allow it to wrap the source code.

  • The idea is that this source code used to pass a test, but no longer due to recent changes in the code. User should then back up the source code, set up the framework, and run the Delta Debugging Algorithm to find the last revision that passes the test.


Build Script

  • This is a Perl file (.pl), and should be named accordingly (e.g. HelloBuild.pl, SudokuBuild.pl).
  • This file contains the script needed to properly build the source code. This script is located in the build() function, which will be called by the algorithm.
  • The separation of the build file from the rest of the code allows user to select and customize various build systems or compilers that exist in the market. Whether the source code requires certain compiler, or uses Makefile for the GNU Make, this file handles the customization.

Test Cases