1. Tools for Agile Development: A Developer’s Perspective Mike Linnen Email: mike@protosystem.net mike@protosystem.net Blog: http://www.protosystem.net http://www.protosystem.net Twitter: http://www.twitter.com/mlinnen http://www.twitter.com/mlinnen

2. Mike Linnen ► Sr. Software Engineer ► Certified ScrumMaster ► Applying Agile practices for 3.5 years ► Over 20 years developing software solutions Blog: http://www.protosystem.net http://www.protosystem.net Twitter: http://www.twitter.com/mlinnen http://www.twitter.com/mlinnen Email: mike@protosystem.net

3. Introductions ► Name ► Company ► Programming Languages

4. Overview ► Focus on experience not theory ► What is important ► Tools used in an Agile environment  What worked  Alternative tools  Future tools  Demos ► Design Patterns  Emerging Design

5. Demos ► Unit Testing  Running tests with NUint & Test Driven.Net  Code Coverage  Mocking ► Continuous Build  Setting up a Continuous Integration Build ► Automated Testing web pages

6. Why? – Features are not removed

7. Why? – Code base grows

8. Why? – Other Benefits ► Enabling Emerging designs ► Refactoring of code without fear ► Embracing Business requirement changes ► Remaining Agile!!!

9. Why? – Aha Moments ► UI Developer – “Since the backend developers started unit testing their code, I have become so much more productive. I actually enjoy developing again.” ► QA Tester – “New features come to me working the first time. I can spend my time looking for edge case bugs instead of logging obvious issues that should have never existed.”

10. Project Release Cycle ► Sprint 0  Short sprint (5 days)  No business value  Setup development environment ► Sprint 1 – N (10 days)  Always contains business value  Incremental infrastructure improvements if necessary  Incremental improvements to development process ► Release Sprint(s)  1 or More sprints  Focus on QA and Promoting to Prod environment

11. What is important? ► Everything is prioritized  Value ► Keeping development cost down ► Business Value  Refining Development Process (write better code faster) 1. Securing your source: Source Control 2. Does it still work: Unit Testing 3. Repeatability: Automated Build 4. Comfort: Unit Test execution for every build 5. Measurements: Code Coverage 6. Integration: Functional Test execution for every build 7. Deployment: Packaging 8. Measurements: Static Analysis

12. Source Control ► SourceGear Vault  Easy integration with automated build ► Command line interface that is called from the build  Familiar GUI (similar to Source safe)  Remote access via web services  Cost effective  Decent Differencing view  Good performance  Can easily determine the status of your local source vs what is in the repository  Uses SQL Server for the repository

13. Source Control - Alternatives ► Source Safe – 6d/2005  No remote access, file based ► SourceGear – Source Offsite  Sits on top of source safe  Has remote access  If you used Source Safe before this will be an upgrade  SourceGear Vault is not that much more in price and gives you so much more ► Subversion (SVN) Free  Has remote access and it works well disconnected too ► Microsoft - Team Foundation Server (TFS)  Workgroup or Enterprise  Not designed for disconnected use  Can be costly

14. Unit Testing ► Unit Testing Framework  NUnit (Free) ► Easy Execution of tests  Test Driven.Net – Visual Studio IDE ► Code Coverage – Test effectiveness  NCover (Free $) ► Mocking dependencies  Rhino Mocks (Free)

15. Unit Testing – Alternatives ► Unit Testing Framework  MbUnit (Free) -  MSTest (Free?) – Microsoft Unit Testing framework ► Slow execution of single tests. Makes TDD difficult. ► Nice IDE integration of code coverage results  xUnit (Free) - ► By design no support for setup and teardown of fixture

16. Unit Testing – Alternatives ► Code Coverage  MSTest ► Mocking dependencies  Moq (Free)  Nmock (Free)  EasyMock (Free)  TypeMock

17. Demo - Unit Testing ► Unit Testing with Nunit  NUnit GUI  Test Driven.Net ► Code Coverage ► Mocking

18. Lessons Learned: Unit Testing ► Don’t mix Unit Tests with Integration Tests  Mock out dependencies ► Design with testing in mind  Use Interfaces between components  Use Interfaces on external dependencies  Use TDD ► Make sure you are evaluating the results

19. Unit Testing - TDD ► Test Driven Development 1.Write failing tests 2.Add code to get the tests to pass 3.Refactor the code for quality 4.Repeat 1. ► How we used TDD

20. Lessons Learned: TDD ► TDD is hard ► Use TDD for complex problems ► Use TDD for educational purposes  Understanding new technologies

21. Automated Build ► Continuous Integration build with CI Factory and CCNet  Build is triggered if a source modification is detected  Capability to run Metrics, Code Analysis, and Automated tests after every build  Easy integration with reporting tools that outline build results (Code coverage/Quality, LOC, Cyclomatic Complexity, etc.)  Fast to get running  Real-time notification of build status  Extensible

22. Automated Build - Alternatives ► CCNET without CI Factory (Free)  This looked way painful ► NAnt (Free)  Roll your own build scripts ► TeamCity (Free Professional Edition)  Nice out of the box installation experience  Not sure about extensibility for unsupported build components ► Team Foundation Server Build (Part of TFS)  Easy to get going once TFS is set up  Supports build types. (CI, Nightly….) ► FinalBuilder

23. CI Build Components ► CI Factory, CCNet, NAnt ► NUnit – Unit Testing ► WatiN – UI Automated testing ► NCover – Code coverage ► SourceGear – Vault source control ► NDepend – Static Analysis ► Sandcastle – Code documentation ► LinesOfCode – Lines of code counter ► Versioning – Versioned the assemblies

24. Demo – CI Build ► Continuous Integration Overview w/CI Factory  Existing Build ► Reporting integration ► Build Notification ► Forcing builds

25. Demo – Create CI Build ► Create a Continuous Integration build using CI Factory ► Add the source of an existing project to the build ► Execute the build

26. Lessons Learned: CI Build ► Keep the build short  Run Integration Tests nightly ► Don’t under estimate the time it takes to extend the build (time box) ► Trust the build and integrate your code often. Don’t keep things checked out. ► Failing Unit Tests must fail the build ► Keep Developer build and CI Build execution the same

27. UI Automated Testing ► NUnit WatiN  IE execution of web application ► IE Developer Toolbar ► Firebug

28. UI Automated Testing - Alternatives ► NUnitAsp (Free)  Missing functionality  Development stopped ► TestComplete – AutomatedQA ► Watir (Free)  WatiN was based on this  Write tests in Ruby ► Visual Studio

29. UI Automated Testing Demo ► Demonstration of UI testing with WatiN

30. Lessons Learned: UI Testing ► Don’t create these tests too early ► Think about making these tests part of a nightly build.  These tests take a long time to run ► Focus on business processes that are important ► Third party components can make testing difficult ► No good free solution for WPF testing

31. Design Patterns ► Separate business logic from user-interface  Various flavors of the Model-View-Controller (MVC) pattern ► Model-View-Controller (MVC)  Custom Built w/ Unity for dependency injection ► Model-View-Presenter (MVP)  Web Client Software Factory (WCSF)  Benefits ► Business logic is easily testable ► Loosely-coupled UI and Business implementation

32. Database Maintenance ► Custom console tool built in 2 days  Versions the database  Applies SQL Scripts in a specified order  Upgrades a DB from its current version to the target version by applying only the required scripts

33. Future ► Integrate stories with build  Know what stories made it into the build  Generate release notes ► Automated deployment of DB Scripts ► Automate Metrics like Lines Of Code ► Automated deployment of the build to QA box and execution of UI Automated tests ► More Static analysis ► Break up build into CI and Nightly ► Make build maintenance/trouble shooting easier

34. Other Tools ► Wiki  Release Notes  General Dev Documentation

35. Other Tools ► TFS – Scrum Dashboard manages sprint

36. Other Tools ► Google Docs

37. End Mike Linnen Email: mike@protosystem.net mike@protosystem.net Blog: http://www.protosystem.net http://www.protosystem.net Twitter: http://www.twitter.com/mlinnen http://www.twitter.com/mlinnen