Home

Features

Case Studies

Video Demos

Publications

People

Contact

The Domain-Specific Language (DSL) Testing Studio assists in debugging and testing a program written in a DSL. It uses a grammar-driven automatic approach to generate the end-users DSL testing tools (e.g., debugger, unit test engine, and profiler) for various categories of DSLs (e.g., imperative, declarative, and hybrid DSL) as illustrated by the figure below.

Motivation:

DSLs assist a software developer (or even an end-user) in writing a program using idioms that are closer to the abstractions found in a specific problem domain. Tool support for DSLs is lacking, however, when compared to the capabilities provided for standard general purpose languages (e.g., support for debugging and testing a program written in a DSL is often non-existent). Manual construction of the IDE for each new DSL can be time-consuming, expensive, and error-prone. The goal of the DSL Testing Studio is to build a DSL Testing Framework using mapping technique for augmenting existing DSL grammars to generate the hooks needed to interface with a supporting infrastructure written for Eclipse that assists in debugging and testing a program written in a DSL. 

Architecture:

An illustrative overview of the software architecture is shown in the figure below: The Mapping Generator components comprise the source code mapping process and the testing methods mapping process (middle of figure). The results from these two mapping processes are reinterpreted into the General Purpose Language (GPL) testing server commands against the translated GPL code. The ANTLR translator generates GPL code and mapping information from the DSL source. The source code mapping process uses the generated mapping information to determine which line of the DSL code is mapped to the corresponding segment of GPL code. It indicates the location of the GPL code segment. The testing methods mapping process takes the user’s testing commands from the debugger and unit test perspective at the DSL level to determine what type of debugging and testing commands need to be issued to a command line testing server at the GPL level.

The GPL testing server responds to the testing commands sent from the Re-interpreter. The testing result from issuing the testing command at the GPL level is sent back to a Re-Mapping component. Because the messages from the GPL testing server are command line outputs, which know nothing of the DSL or the Eclipse debug platform, it is necessary to remap the results back into the end-users perspectives. The Re-Mapping component maps the messages back to the DSL level through the wrapper interface.

This research is conducted within the Software Composition and Modeling (SOFTCOM) Laboratory at UAB and is supported by an IBM Eclipse Innovation Grant (EIG).