Agile Open 2009 Tdd And Architecture Influences


Published on

This material was presented at Buenos Aires Agile Open 2009

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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Agile Open 2009 Tdd And Architecture Influences

    1. 1. TDD and Architectural influences <ul><ul><li>Ing. Gustavo A. Brey </li></ul></ul>
    2. 2. Agenda <ul><ul><li>Audience and Goal </li></ul></ul><ul><ul><li>TDD Introduction </li></ul></ul><ul><ul><li>Non Functional Requirements Impact </li></ul></ul><ul><ul><li>Architectural Decisions </li></ul></ul><ul><ul><li>Why People complain about TDD? </li></ul></ul><ul><ul><li>Feedback </li></ul></ul>
    3. 3. Audience and Goal <ul><li>This presentation is intended for IT Application Architects that are on one of the following situation: </li></ul><ul><ul><li>Already implemented TDD on their projects but it is still difficult to have enough code coverage or the productivity had decrease because the Architecture is not supporting TDD correctly. </li></ul></ul><ul><ul><li>Architecture is being designed, during first iterations or plan phase and you want to make sure that TDD will be supported by the Architecture and it will help to address some non runtime NFR. </li></ul></ul><ul><li>IT Architects have to enable NFR, but it is not the only responsible to achieve them. </li></ul>
    4. 4. TDD Introduction <ul><li>Some facts before start regarding TDD: </li></ul><ul><li>TDD involves: </li></ul><ul><ul><li>Unit Test </li></ul></ul><ul><ul><li>Test Automation </li></ul></ul><ul><ul><li>Test First </li></ul></ul><ul><ul><li>Iterative approach along with refactoring </li></ul></ul><ul><li>TDD is a Detailed Design and Code technique and it is mainly targeted for Application Developers/IT Specialist </li></ul><ul><li>TDD increases code quality , therefore it facilitates software changes </li></ul><ul><li>TDD reduces defects and allows constant regression testing </li></ul><ul><li>Dependency Management is the hardest part of TDD </li></ul>
    5. 5. Non Functional Requirements Impacted <ul><li>Qualities </li></ul><ul><ul><ul><li>Maintainability </li></ul></ul></ul><ul><ul><ul><li>Extensibility / Modifiability </li></ul></ul></ul><ul><ul><ul><li>Reliability </li></ul></ul></ul><ul><li>Constrains </li></ul><ul><ul><ul><li>Geographic (including Localization)‏ </li></ul></ul></ul><ul><ul><ul><li>Time </li></ul></ul></ul>
    6. 6. Architectural Decisions <ul><li>Specific Tactics and Architectural Design Principles </li></ul><ul><ul><li>Principles are fundamental to make decisions related to the design and construction of the architected system. </li></ul></ul><ul><ul><li>Tactics aim to achieve one or more NFT </li></ul></ul><ul><li>Architectural Styles </li></ul><ul><ul><li>An architectural pattern in software, also known as an architectural style, is analogous to an architectural style in buildings, such as Gothic or Greek Revival or Queen Anne. It consists of a few key features and rules for combining them so that architectural integrity is preserved </li></ul></ul>
    7. 7. Specific Tactics and Architectural Design Principles <ul><li>Separation of concerns </li></ul><ul><ul><li>This principle is also propagated to TDD Code, handle better the complexity </li></ul></ul><ul><ul><li>Allows code reuse between test and is key helping defining the behavior of Mock and Fake Objects </li></ul></ul><ul><li>Separation of interface and implementation </li></ul><ul><ul><li>Allows works in parallel letting you implement your own Mock and Fake objects from different Modules/Components giving a Test environment to test functional code (SUT). </li></ul></ul><ul><li>Design by contract </li></ul><ul><ul><li>There is some sort of overlap here, but depending on the platform or language that the application is being written. However, from an architectural point of view both techniques are complementary. </li></ul></ul><ul><li>Information hiding </li></ul><ul><ul><li>As well as SoC, it gives a better environment to work with module dependencies. </li></ul></ul><ul><li>Prevent Ripple Effects </li></ul><ul><ul><li>Restrict communication paths and Use an intermediary </li></ul></ul>
    8. 8. Architectural Styles and Strategic Design <ul><li>Inversion of Control and Dependency Injection </li></ul><ul><li>Hierarchical Layers </li></ul><ul><li>Transaction Scripts or Service Oriented </li></ul><ul><li>Domain Driven Design </li></ul>
    9. 9. Inversion of Control (IoC) and Dependency Injection (DI)‏ <ul><li>Few words about IoC and DI: </li></ul><ul><ul><li>It is a simple and smart way of handling dependencies , it has been replacing de facto Singleton Service Locator (Anti Pattern)‏ </li></ul></ul><ul><ul><li>A third party entity (i.e. container) inject all objects/module dependencies base on an input that can be a DSL like XML Config File, Annotations or simple Java Code (or groovy)‏ </li></ul></ul><ul><ul><li>It relies on Separation of Concerns and Separation of interface and implementation design principles. </li></ul></ul><ul><li>Ok with IoC and DI, but what about TDD integration? </li></ul><ul><li>You can wire all object/service dependencies for the test case that you want to run, injecting Mocks and Fakes Objects without calling real dependencies and having all the coverage needed. </li></ul><ul><li>Other architectural advantages by using IoC/DI: </li></ul><ul><li>Object Life Cycle Management </li></ul><ul><li>Support for Cross Cutting Concerns (Aspect Oriented Programming)‏ </li></ul><ul><li>Less and Clean Code </li></ul>
    10. 10. Hierarchical Layers <ul><li>It is a well known architectural style, most Enterprise Application use this style. </li></ul><ul><li>Each layer gives services to one upper layer. </li></ul><ul><li>It is a simple Module Dependency scenario and each layer (module) can be fully tested “Mocking” only one layer. </li></ul><ul><li>There are some concerns regarding the use of Layers: </li></ul><ul><li>It is not always easy to find the correct abstraction and allocate the correct responsibility on each layer </li></ul><ul><li>The usage of layers use to cause less object oriented models </li></ul><ul><li>There are certain cases when a small change would cause a change all around the layers </li></ul>UI Business Data
    11. 11. Transaction Scripts and Domain Driven Design <ul><li>Transaction Scripts </li></ul><ul><li>The application is a set of Services with a clear interface which can be called </li></ul><ul><li>It is and works ok with parallel programming. Simple! </li></ul><ul><li>Each service is Stateless </li></ul><ul><li>It is difficult to reuse and scale in terms of functionalities (like structured programming/call & return)‏ </li></ul><ul><li>While building a Service, it can be isolated (using DI) from other Services, so with all dependencies mocked TDD is easy. </li></ul><ul><li>Domain Driven Design </li></ul><ul><li>The focus of this Methodology & Architectural Style is on the Domain </li></ul><ul><li>Architecture should not be intrusive </li></ul><ul><li>Extreme the usage of Object Oriented (stateful) or Business Modeling, so it is easy and simple to reuse and scale in functionality. </li></ul><ul><li>DDD fits perfect with TDD, Agile and Iterative Methodologies, maximizing the use of Objects, DI and Refactoring. Definitively for complex domains </li></ul>
    12. 12. Why People complain about TDD? <ul><li>Project Managers </li></ul><ul><ul><li>It takes too much time to write the tests. Impacts productivity. </li></ul></ul><ul><ul><li>I feel guilty about putting testers and QA staff out of work </li></ul></ul><ul><li>Architects </li></ul><ul><ul><li>I don’t care about TDD, it is just low level stuff and it doesn’t impact the architecture </li></ul></ul><ul><ul><li>There’s no need to test drive the code, because the design handed to me by the architect covers every possibility </li></ul></ul><ul><li>Application Developers </li></ul><ul><ul><li>It takes too long to run the tests </li></ul></ul><ul><ul><li>It's not my job to test my code </li></ul></ul><ul><ul><li>I don't really know how the code is supposed to behave so I can't test it </li></ul></ul><ul><ul><li>But it compiles! </li></ul></ul><ul><ul><li>I'm being paid to write code, not to write tests </li></ul></ul><ul><ul><li>Dependency is complex to handle </li></ul></ul>
    13. 13. Conclusion <ul><li>“ Every copy of a program should include some small test cases that can be routinely used to reassure the user that he has a faithful copy, accurately loaded into the machine. Then one needs more thorough test cases, which are normally run only after a program is modified. These fall into three parts of the input data domain: </li></ul><ul><ul><li>Mainline cases that test the program's chief functions for common encountered data. </li></ul></ul><ul><ul><li>Barely legitimate cases that probe the edge of the input data domain, ensuring that largest possible values, smallest possible values, and all kinds of valid exceptions work. </li></ul></ul><ul><ul><li>Barely illegitimate cases that probe the domain boundary from the other side, ensuring that invalid inputs raise proper diagnostic messages.” </li></ul></ul><ul><li>Fred Brooks, The Mythical Man Month, 1975 </li></ul>
    14. 14. Resources <ul><li>Pragmatic Unit Testing in Java with JUnit </li></ul><ul><ul><li>By Andy Hunt and Dave Thomas. Publisher : The Pragmatic Bookshelf. Pub Date : September 2003. ISBN : 0-9745140-1-2 </li></ul></ul><ul><li>Test-Driven Development: A Practical Guide </li></ul><ul><ul><li>By David Astels. Publisher : Prentice Hall PTR. Pub Date : July 02, 2003. ISBN : 0-13-101649-0 </li></ul></ul><ul><li>Working Effectively with Legacy Code </li></ul><ul><ul><li>By Michael C. Feathers. Publisher : Prentice Hall PTR. Pub Date : September 22, 2004. ISBN : 0-13-117705-2 </li></ul></ul><ul><li>Software Architecture in Practice, Second Edition </li></ul><ul><ul><li>By Len Bass, Paul Clements, Rick Kazman. Addison Wesley, 2003, ISBN 0-321-15495-9. </li></ul></ul><ul><li>Patterns of Enterprise Application Architecture. </li></ul><ul><ul><li>By Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford. Addison Wesley, 2002, ISBN 0-321-12742-0. </li></ul></ul>