Test-driven development and Umple
Upcoming SlideShare
Loading in...5
×
 

Test-driven development and Umple

on

  • 79 views

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.

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.

Statistics

Views

Total Views
79
Views on SlideShare
70
Embed Views
9

Actions

Likes
0
Downloads
3
Comments
0

1 Embed 9

http://www.slideee.com 9

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Test-driven development and Umple Test-driven development and Umple Presentation Transcript

    • Test-driven development and Umple
    • 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.
    • 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.
    • 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
    • “Red/green/refactor”  The TDD mantra, “Red/green/refactor” is visually depicted as a repetitive process in the figure below.
    • 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
    • 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.
    • 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
    • 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.
    • 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.
    • 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
    • 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
    • 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
    • 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
    • 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.