370 likes | 564 Views
Tools for Agile Development: A Developer’s Perspective. Mike Linnen Email: mike@protosystem.net Blog: http://www.protosystem.net Twitter: http://www.twitter.com/mlinnen. Mike Linnen. Sr. Software Engineer Certified ScrumMaster Applying Agile practices for 3.5 years
E N D
Tools for Agile Development: A Developer’s Perspective Mike Linnen Email: mike@protosystem.net Blog: http://www.protosystem.net Twitter: http://www.twitter.com/mlinnen
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 Twitter: http://www.twitter.com/mlinnen Email: mike@protosystem.net
Introductions • Name • Company • Programming Languages
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
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
Why? – Other Benefits • Enabling Emerging designs • Refactoring of code without fear • Embracing Business requirement changes • Remaining Agile!!!
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.”
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
What is important? • Everything is prioritized • Value • Keeping development cost down • Business Value • Refining Development Process (write better code faster) • Securing your source: Source Control • Does it still work: Unit Testing • Repeatability: Automated Build • Comfort: Unit Test execution for every build • Measurements: Code Coverage • Integration: Functional Test execution for every build • Deployment: Packaging • Measurements: Static Analysis
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
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
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)
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
Unit Testing – Alternatives • Code Coverage • MSTest • Mocking dependencies • Moq (Free) • Nmock (Free) • EasyMock (Free) • TypeMock
Demo - Unit Testing • Unit Testing with Nunit • NUnit GUI • Test Driven .Net • Code Coverage • Mocking
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
Unit Testing - TDD • Test Driven Development • Write failing tests • Add code to get the tests to pass • Refactor the code for quality • Repeat 1. • How we used TDD
Lessons Learned: TDD • TDD is hard • Use TDD for complex problems • Use TDD for educational purposes • Understanding new technologies
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
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
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
Demo – CI Build • Continuous Integration Overview w/CI Factory • Existing Build • Reporting integration • Build Notification • Forcing builds
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
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
UI Automated Testing • NUnitWatiN • IE execution of web application • IE Developer Toolbar • Firebug
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
UI Automated Testing Demo • Demonstration of UI testing with WatiN
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
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
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
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
Other Tools • Wiki • Release Notes • General Dev Documentation
Other Tools • TFS – Scrum Dashboard manages sprint
Other Tools • Google Docs
End Mike Linnen Email: mike@protosystem.net Blog: http://www.protosystem.net Twitter: http://www.twitter.com/mlinnen