1. Test-driven development and Umple

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. 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. Test-driven development (TDD) TDD is a software development process with two main rules: 1. Dont 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. Red/green/refactor The TDD mantra, Red/green/refactor is visually depicted as a repetitive process in the figure below. 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 developers local environment before they are committed to source Ensure the changes dont affect other areas of the source code Potentially catch errors we may have missed without tests 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 Umples architecture. 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. TDD & Umple contd 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. 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. Practical Example Refactoring contd 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. Practical Example Refactoring contd 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 (wouldnt even compile) because the new method had not been created yet 13. Practical Example Refactoring contd 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 hadnt passed, would have modified the method and run the tests again 14. Practical Example Refactoring contd 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. 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.