Test-driven development and
Umple
Introduction
 Test-driven development is a very common
development process for open-source
software projects, especially ...
Umple
 Umple is a language used for both object-oriented
programming and modeling with class and state
diagrams.
 The na...
Test-driven development (TDD)
 TDD is a software development process with two
main rules:
1. Don‟t write a new line of co...
“Red/green/refactor”
 The TDD mantra, “Red/green/refactor” is visually
depicted as a repetitive process in the figure bel...
Benefits of TDD
 By writing automated tests first during
development, we can:
• Fully imagine and plan our changes before...
Testing in Umple
 There are several levels of testing in the Umple compiler.
Testing also exists for all of the non-compi...
TDD & Umple
 TDD complements the collaborative and
distributed way in which Umple is developed
 Umple is developed using...
TDD & Umple cont‟d
 The figure below shows an example of the continuous
integration process which relies on TDD. Changes ...
Practical Example – Refactoring Some Code
 Revision r3915 provides a clean example of how
refactoring can work in a TDD e...
Practical Example – Refactoring cont‟d
 Steps taken to complete code changes in Revision
r3915:
1. Analysed the code need...
Practical Example – Refactoring cont‟d
 Steps taken to complete code changes in Revision
r3915:
2. (RED) - Wrote unit tes...
Practical Example – Refactoring cont‟d
 Steps taken to complete code changes in Revision
r3915:
 (GREEN) - Created the n...
Practical Example – Refactoring cont‟d
 Steps taken to complete code changes in Revision
r3915:
 (REFACTOR) – Cleaned up...
Conclusion
 The TDD process integrates very well with the
distributed nature of development on an open-
source project.
...
Upcoming SlideShare
Loading in …5
×

Test-driven development and Umple

292 views

Published on

A brief overview of the open-source software project Umple and how contributors to the project use test-driven development (TDD) to easily modify and expand the source code.

Published in: Software, Technology
  • Be the first to comment

  • Be the first to like this

Test-driven development and Umple

  1. 1. Test-driven development and Umple
  2. 2. Introduction  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, should be done using TDD principles. This decision leads to more manageable, understandable code.
  3. 3. 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.
  4. 4. Test-driven development (TDD)  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
  5. 5. “Red/green/refactor”  The TDD mantra, “Red/green/refactor” is visually depicted as a repetitive process in the figure below.
  6. 6. Benefits of TDD  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 • Changes must be fully tested on a developer‟s local environment before they are committed to source • Ensure the changes don‟t affect other areas of the source code • Potentially catch errors we may have missed without tests
  7. 7. Testing in Umple  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 as follows: • 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.
  8. 8. TDD & Umple  TDD complements 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
  9. 9. TDD & Umple cont‟d  The figure 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.
  10. 10. Practical Example – Refactoring Some Code  Revision r3915 provides a clean example of how refactoring can work in a TDD environment.  The goal of this revision was to extract a portion of code from the method „checkDefaultedNameConflict()‟ in the „UmpleInternalParser_Code.ump‟ class so said code could be put into its own method and used in other places.  Instead of having this code at the parser level, it makes more sense to have it at the model level.
  11. 11. Practical Example – Refactoring cont‟d  Steps taken to complete code changes in Revision r3915: 1. Analysed the code needing to be extracted and determine where it will reside once it has been refactored.  In this case, the code was suited to be moved to the „UmpleModel‟ class  The figure below shows the code needing to be extracted in red
  12. 12. Practical Example – Refactoring cont‟d  Steps taken to complete code changes in Revision r3915: 2. (RED) - Wrote unit tests for the new method based on expected behaviour.  All of the tests went in the „UmpleModelTest‟ class (at the metamodel level) as can be seen in the figure below  These tests all initially failed (wouldn‟t even compile) because the new method had not been created yet
  13. 13. Practical Example – Refactoring cont‟d  Steps taken to complete code changes in Revision r3915:  (GREEN) - Created the new method in its new location and ran the unit tests  In the „UmpleModel‟ class, the new method „getAllTranslators()‟ was created using code extracted from the „checkDefaultedNameConflict()‟ method, as can be seen in the figure below  Ran tests and they all passed; therefore, new method behaved as expected  If tests hadn‟t passed, would have modified the method and run the tests again
  14. 14. Practical Example – Refactoring cont‟d  Steps taken to complete code changes in Revision r3915:  (REFACTOR) – Cleaned up code to use the refactored changes  Changed the code in „checkDefaultedNameConflict()‟ method so the new method was being used  The figure below shows the refactored code in green
  15. 15. Conclusion  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.

×