The document discusses a research project on test-driven development (TDD) applied to the open-source software Umple, highlighting the benefits of TDD in enhancing code reliability and maintainability. It details the structured process of TDD, including writing automated tests before code implementation, and describes various levels of testing within the Umple compiler. The document emphasizes the importance of TDD principles in facilitating contributions to the Umple project and ensuring a collaborative development environment.

1. Test-driven development and Umple
UCOSP - Winter 2014
Tyler McConnell, supervised by Dr. Nora Znotinas,
CP494: Directed Research Project II, Wilfrid Laurier University
INTRODUCTION TESTING IN UMPLE
This poster has been completed as part of
the requirements for the course CP494:
Directed Research Project II. For my
directed research project, I have had the
privilege of partaking in the
Undergraduate Capstone Open-Source
Projects (UCOSP) program.
Through this program, I have worked on
the open-source software project Umple
with a distributed team of software
developers from universities all over the
world. The UCOSP program has provided
me with real-world development
experience and has introduced me to the
challenges of software development with
a distributed team.
Anyone interested in the UCOSP program
should contact the Physics & Computer
Science faculty office for more
information.
ADDITIONAL INFO
Test-driven development (TDD) is a software
development process with two main rules:
1. Don’t write a new line of code unless you have a
failing automated test.
2. Eliminate duplication.
These two rules imply an order to the tasks of
programming in a TDD environment:
• Developer writes an (initially failing) automated
test case that defines the desired improvement
or new functionality
• Developer writes the minimum code required to
pass the automated test case
• Developer refactors the new code to acceptable
standards
The TDD mantra, “Red/green/refactor” is visually
depicted as a repetitive process in Figure 1 to the
right.
Test-driven development is a very common
development process for open-source software
projects, especially those which adhere to Agile
principles or which use continuous integration.
All development for the open-source UML
programming language, Umple, is done using TDD
principles. This decision leads to more manageable,
understandable code.
There are several levels of testing in the Umple compiler.
Testing also exists for all of the non-compiler
components. The primary levels of compiler testing are:
• Parser tests: verify that a construct parses correctly
• Metamodel tests: check that the metamodel is
populated correctly by the various umple constructs
• Template tests: verify that the generated output in
languages like Java is as expected
• Testbed tests: verify that compiled code that
generates languages such as Java can then compile
under the language compiler
• User manual tests: verify that examples in the user
manual can properly run
The separation of testing levels comes naturally from the
hierarchal components of Umple’s architecture.
Figure 2 shows some code snippets from the Umple
code base. ConstraintTest exists at the metamodel level.
TDD works harmoniously with the collaborative and
distributed way in which Umple is developed.
Umple is developed using a continuous integration
process, which works very well with TDD. The
continuous integration process makes it so that any
changes committed to the Umple source repository
are immediately tested to ensure that they do not
negatively effect the build.
Figure 3 below shows an example of the continuous
integration process which relies on TDD. Changes
are committed to the code base until an error is
detected by the build process. Once an error is
detected, action must be taken to resolve that error
before any other new commits can be integrated
into the source repository.
By writing automated tests first during
development, we can:
• Fully imagine and plan our changes before
actually implementing them
• Ensure the changes produce expected
behaviours
• Ensure the changes don’t affect other areas of
the source code
• Potentially catch errors which we may have
missed without tests
TDD & UMPLE
CONCLUSIONS
The TDD process integrates very well with the
distributed nature of development on an open-
source project. By adhering to TDD principles,
contributors to the Umple project are ensuring that
the code is reliable and maintainable, and are
making it easier for new developers to contribute in
the future.
Figure 3. Example of continuous integration and test-driven development relationship.
Figure 1. Visual depiction of order of TDD tasks.
TEST-DRIVEN DEVELOPMENT (TDD)
UMPLE
Umple is a language used for both object-oriented
programming and modeling with class and state
diagrams.
The name Umple is a portmanteau of “UML”,
“ample”, and “programming language”. This is
meant to convey that Umple provides ample
features to extend programming languages with
UML capabilities, such as Java, PHP, or Ruby. Code
can also be generated in these mentioned
languages from a source Umple file.
Created in 2008, Umple was open-sourced in 2011
when it was released publicly on Google Code.
/*
* A pared-down Constraint object
*/
class Constraint {
isA CodeBlock;
format = "allParameterClosed";
String inject = "";
CodeTranslator gen = null;
boolean negated = false;
String code = { StringFormatter.format(getGen().translate(
(getNegated()?"Not":"")+getFormat(),this),
getInject())};
}
public class ConstraintTest {
Constraint constraint;
@Before
public void setUp() {
constraint = new Constraint();
constraint.addExpression(new ConstraintVariable("ATTRIBUTE","foo"));
constraint.setInject("bar");
}
@Test
public void getCode_javaGen() {
constraint.setGen(new JavaGenerator());
String expected = "if (foo)n{n barn}";
assertEquals(expected, constraint.getCode());
}
@Test
public void getCode_rubyGen() {
constraint.setGen(new RubyGenerator());
String expected = "if @foo thenn barnend";
assertEquals(expected, constraint.getCode());
}
…
}
Figure 2. Example Constraint.ump file
and its corresponding test class.