Your SlideShare is downloading. ×
Ese2008 George Mesesan Tdd Symposium
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ese2008 George Mesesan Tdd Symposium


Published on

Published in: Technology, Business

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. MicroDoc Computersysteme GmbH Author: George Mesesan Date: Oct. 22, 2008 Can Test Driven Development be integrated into existing projects ? Topic outline: Integrating Test Driven Development into an existing project is no easy task. The biggest challange is moving the testing effort from the end of the development phase to the beginning, and at the same time keeping the project on track, on time and on budget for the next release. Whereas in a classical quot;Test-Lastquot; development process you typically test the application manually through the GUI, in a Test- Driven Development process you need to write your tests first, including GUI testing. One hidden advantage is, that by writing tests firsts, you take a big step towards test automation. If we consider that GUI tests are the simplest form of acceptance testing, then we suddenly see the advantage of GUI test automation: quot;executable requirementsquot;. The advantages of TDD over classical aproaches can be best seen on a concrete example: July 2007. One of our embedded Java projects was running for 5 years by now, had about 50.000 lines of code and was composed of 40 OSGi Bundles. We supported two different operating systems, run on three different device types with different amounts of memory. Until recently, the build process was only partially automated. Testing was performed with JUnit tests, but we had no exact information about the code coverage. We also had to execute a large amount of manual tests, mainly for the GUI. This was particularly painful close to release day. At this point we had to support an additional operating system, bringing the total to three, and we needed to integrate a large native component provided by a third party. Additionally, we had to preserve backward compatibility to all previous versions of our software, as well as to the different hardware devices. In the light on this situation, it was clear that we needed to take drastic actions. And we did ! Today the application has about 66.000 lines of code, but we have several layers of testing: unit, integration TDD Sympoium Position Paper, Eclipse Summit, © 2008, MicroDoc GmbH München Page 1
  • 2. and acceptance. We have about 50% code coverage of our tests and as a result of this a clearer picture of the whole project's status. In this symposium I would like to show how we changed our development process, the tools that we created to help us with continuous integration in an embedded OSGi environment and how we moved from quot;Test-Lastquot; manual testing to automated continuous deployment and GUI testing with Fitnesse. The focus will be on practical examples using code snippets and on reusable concepts that can be easily assimilated in other projects. Author: George Mesesan. I am a senior software engineer at MicroDoc GmbH in Munich and I was involved in the introduction of TDD within the MicroDoc development process. I have experience in tools development and automation techniques, in the embedded as well as the enterprise domains. Contact: TDD Sympoium Position Paper, Eclipse Summit, © 2008, MicroDoc GmbH München Page 2