Tools for Agile
Development: A
Developer’s Perspective
Mike Linnen
Email: [email protected]
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: [email protected]
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? – Features are not removed
Busines Value Delivered
(Stories Completed)
250
Cumulative Business Value
200
150
100
50
0
Day
Why? – Code base grows
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
► Sprint
1 – N (10 days)
 Short sprint (5 days)
 No business value
 Setup development environment
 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)
1.
2.
3.
4.
5.
6.
7.
8.
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
1.
2.
3.
4.
►
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
CCNet
Integration build with CI Factory and
 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
Factory
Integration Overview w/CI
 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
► NUnit
WatiN
 IE execution of web application
► IE
Developer Toolbar
► Firebug
UI Automated Testing Alternatives
► NUnitAsp
(Free)
 Missing functionality
 Development stopped
► TestComplete
► Watir
– AutomatedQA
(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: [email protected]
Blog: http://www.protosystem.net
Twitter: http://www.twitter.com/mlinnen
Descargar

Tools for Agile Development: A Developer's Perspective