(9700) DesignWizard: A Tool that Gives Support to Automatically Check Your Code Against Design Rules

Jazoon Rookie

Wednesday, 2009-06-24, 17:00 - 17:20, Arena 5

João Arthur Brunet Monteiro - Federal University of Campina Grande (speaker)

Topics

• Testing tools
• Application testing methodologies

Download the presentation

Abstract

Checking code against design rules is an important activity to guarantee quality 
on source code. It well known that good designers think about good solutions and 
implementations for the problem being addressed, but often, programmers code 
without concerning these important design aspects.

In order to guarantee that the development team is following design decision 
while coding, designers use Design Review, which consists of a mechanism to find 
errors in the design and its representation by splitting the team into groups 
and making them analyze each others' code. The problem with Design Review, being 
a manual process, that it is error-prone and does not scale, since analyzing a 
number of classes may take several hours.

We present a new kind of test, named design test. A design test, as the name 
states, is a test that checks whether an implementation complies with a given 
design rule expressed as an algorithm. Design tests differ from functional tests 
because the latter ones are used to check whether the software does what it is 
supposed to do. On the other hand, design tests check how the software has been 
built.

Unlike Design review, design tests are an automated way to check whether the 
code is following a given design rule. They can be written using existing 
testing harnesses in the same programming language used to develop the software 
under test (we use JUnit in our Java implementation. This has the benefit that 
design rules can be documented in a language that all developers understand. 
Furthermore, as an executable documentation, design tests are more likely to 
keep in synchronization with the actual implementation. We believe this is 
especially useful in development teams in which developers change often and can 
easily miss or misunderstand design decisions.

We also present DesignWizard (DW), a fully fledged API that we have developed to 
allow writing design tests for Java implementations, using the JUnit testing 
framework. We have applied design tests in the development of at least three 
software products we have developed in our labs at UFCG. We have also used 
design tests to assess student projects in undergraduate courses. Our experience 
has shown that using design tests is easy and can be easily incorporated into a 
development process to improve software quality. In particular, we have observed 
that designers and programmers appreciate the use of design tests as an 
executable documentation that can be easily kept up to date. Tests are usually 
easy to write, to read and to maintain. Furthermore, one can easily decide the 
level of rigor necessary to apply to each part of the software, promoting the 
appropriate balance of rigor and freedom. Finally, we have observed that the 
implementation is scalable and that efficiency has not been a problem.

Design test is the key concern of our approach. It is a mechanism to specify 
design rules as algorithms and a mechanism to check code against these design 
rules in an automated way. In order to do so, a designer uses two key 
components: a code structure analyzer API and a testing framework.

The code structure analyzer API is responsible for: i) Extracting facts from 
code; and ii) Exposing an API to recover this information. This component 
applies static analysis to extract information about the structure of the code 
under analysis. The facts extracted must to be modeled as a graph, where the 
nodes are the entities and the edges are relations between them. Finally, this 
component provides an API that offers methods to navigate through this graph.

The testing framework is responsible for: i) providing assertion routines; ii) 
providing an automated way to execute the tests and iii) reporting test's 
results. In our approach, the assertions routines will be used to check not the 
functionality of the code, but its structure.

The result of the execution has a different interpretation from the results a 
functional test. A success in the execution of a design test means that the code 
analyzed follows the design rules described. By the other side, a failure 
denotes that the code does not follow the specified design rule.

In our implementation of the design test approach, DW plays the role of the code 
structure analyzer API, while JUnit has been used to provide assertions, execute 
and report the results of a design test execution.