Benjamin Day – VSTS/TFS Workshop 1

Transcription

Benjamin Day – VSTS/TFS Workshop
Getting the Most
Mileage Out Of Team
System: A Developer’s
Perspective
About the speaker
z
Benjamin Day
Owner, Benjamin Day Consulting, Inc.
– Email: benday@benday.com
– Web: http://www.benday.com
p //
y
– Blog: http://blog.benday.com
Benjamin Day Consulting, Inc
z
Trainer
z
Microsoft MVP for C#
Microsoft VSTS/TFS Customer Advisory
Council
Leader of Beantown.NET INETA User Group
– Visual Studio Team System, Team Foundation Server
z
z
Agenda
z
z
z
z
z
z
Section 1: TFS & VSTS Overview
TFS & VSTS Overview
Unit Testing & Test-Driven Development
Team Projects
Source
Sou
ce Co
Control
to
Database Development with VSTS
TFS Build System
Visual Studio
Visual Studio
Team Architect
Team Developer
Application Designer
Dynamic Code Analyzer
Load Testing
Logical Infra.
Designer
Static Code Analyzer
Manual Testing
Deployment Designer
Code Profiler
Test Case Management
Team Test
Unit Testing
Code
d Coverage
Class Designer
Visio and UML Modeling
Team Foundation Client (includes CAL)
Visual Studio Professional Edition
Visual Studio
Team
Foundation
Big Build
Visual Studio Team Architect
Visual Studio
Visual Studio Ind
dustry Partners
Process and Architecture Guidance
Visual Studio Team System
Change Management
Reporting
Integration
Services
Work Item Tracking
Project Site
Project Management
5
© 2007 Benjamin Day Consulting, Inc.. All rights reserved.
z
z
Logical Infrastructure Designer
z
Deployment Designer
Class
C
ass Designer
es g e
z
No unit testing
z
6
1
Visual Studio
Visual Studio
Team Architect
Team Developer
Load Testing
Logical Infra.
Designer
Manual Testing
Deployment Designer
Code Profiler
Team Test
Unit Testing
Code
d Coverage
Class Designer
Visual Studio
Team
Foundation
Big Build
Visual Studio Team Developer
Visual Studio
Visual Studio Ind
dustry Partners
Change Management
Reporting
Integration
Services
Work Item Tracking
Project Site
Project Management
z
z
z
z
z
Code Profiler
Unit Testing
Code Coverage
Class Designer
7
8
Visual Studio
Visual Studio
Team Architect
Team Developer
Load Testing
Logical Infra.
Designer
Manual Testing
Deployment Designer
Code Profiler
Team Test
Unit Testing
Code
d Coverage
Class Designer
Visual Studio
Team
Foundation
Big Build
Visual Studio Team Tester
Visual Studio
Visual Studio Ind
dustry Partners
Change Management
Reporting
Integration
Services
Work Item Tracking
Project Site
Project Management
z
z
z
z
z
z
Load Testing
Manual Testing
Web
eb Testing
est g
Unit Testing
Code Coverage
9
10
Visual Studio
Visual Studio
Team Architect
Team Developer
Load Testing
Logical Infra.
Designer
Manual Testing
Deployment Designer
Code Profiler
Team Test
Unit Testing
Code
d Coverage
Class Designer
Visual Studio
Team
Foundation
Big Build
Visual Studio Database Professional
Visual Studio
Visual Studio Ind
dustry Partners
Change Management
Reporting
Integration
Services
Work Item Tracking
Project Site
Project Management
11
z
z
z
z
z
z
z
Released December 2006
Source control for database schemas
Database object “rename” refactoring
Test
est data ge
generator
e ato
Database unit tests
Schema comparisons
Table data comparison
12
2
Visual Studio
Visual Studio
Team Architect
Team Developer
Load Testing
Logical Infra.
Designer
Manual Testing
Deployment Designer
Code Profiler
Team Test
Unit Testing
Code
d Coverage
Class Designer
Visual Studio
Team
Foundation
Big Build
The Glue: Team Foundation Server
Visual Studio
Visual Studio Ind
dustry Partners
Change Management
Reporting
Integration
Services
Work Item Tracking
Project Site
Project Management
z
Binds all the developers together
z
Streamlines project management and
communication
Provides a unified environment for managing
– Enables the “System” in Team System
z
– Task assignments
– Progress data
– Bug data
– Source control
– Builds
– Unit test data
13
14
Software projects tend to have
problems…a lot.
z
z
Why?
z
z
z
Standish Group’s “Chaos Report” from 2003
13522 IT projects
34% of projects succeed (16% in 1994)
15%
5% of
o project
p oject failed
a ed (3
(31%
% in 1994)
99 )
51% of projects “challenged”
– 54% of “challenged” Æ more than 20% over-budget
from Business Wire, March 25, 2003
15
16
Success by project size for 2000
Standish Group project definitions
z
Successful project
– Completed within +/- 10% of cost and schedule
estimate
– All intended functions
z
Challenged projects
– Late
– >10% over budget
– Reduced functions
z
From “Why Big Software Projects Fail” by Watts Humphrey, CrossTalk: Journal Of Defence Software
Engineering, March 2005
17
z
Failed Projects
– Never delivered anything
18
3
TFS and Team System: Why do we
need it?
Why do software projects fail?
z
z
Poor requirements
Requirements shift
z
z
Do you really want to work around the clock?
Do you love “death march” projects?
– Scope creep
– People change their minds
z
Disconnect between management, customer,
and the development team
z
Poor task estimation (unrealistic schedule)
z
Failure to recognize and manage risk
z
z
– No unified “big picture” view
z
z
z
Microsoft wants you to be successful
Test-driven development is an accepted best
practice
Difficult to determine project status
Team communication overhead
Microsoft had no “enterprise” version control
solution
19
20
TFS: Why do we need it?
z
z
z
z
Team System
Improves communication
Expectations of management get out of sync
with the reality that developers see
Geographically dispersed teams (different
offices, time zones, countries) exacerbate the
communication problem
TFS provides a single place where all data
and artifacts of a product are stored and
reported on so that all stakeholders in the
product can have a shared understanding
z
z
– Built-in unit testing, code coverage, code profiling
(Another unit test framework?!)
– Static code analysis
– Integrates with Team Foundation Server
z
z
TFS Architectural Overview
z
TFS is an n-tier application
Client-side (Presentation)
z
z
Server-side (Presentation)
(
)
Work item management
Reporting
Source control
Build management
Project guidance documentation
Not all features will be used by everyone Æ role
centric
22
Team Explorer
z
– Visual Studio .NET 2005 Team Edition
– Team Explorer
z
Team Foundation Server
–
–
–
–
–
21
z
Focused on increasing the predictability of
success
Visual Studio
z
Plug-in for Visual Studio Team System
Your interface to TFS
Not part of the VSTS installation
Install
sta itt from
o tthe
e TFS
Sd
disk
s
– SharePoint Services 2.0
– SQL Reporting Services
z
TFS Web Services
“Business” Tier
z
Database Tier
z
– Team Foundation Server
– SQL Server 2005
– 11 Databases
23
24
4
Team Project
z
Similar to a “solution” in Visual Studio
Has a development process (aka
methodology)
z
Container for all items related to the project
z
Questions?
– Agile, CMMI, or Scrum
– Work items (TFS)
– Documents (Sharepoint)
– Reports (SQL Reporting Services, Excel)
– Builds (TFS)
– Source Code (TFS)
25
Section 2: Unit Testing
z
z
z
z
z
z
z
z
What is unit testing & TDD?
What are all different test types?
How do you design for testability?
What’s
at s a “mock”
oc object?
object
How do you test user interface functionality?
What’s code coverage?
Why would you want to use code profiling on
your unit tests?
What’s the best way to unit test your stored
procedures?
What is a Unit Test?
z
z
Wikipedia says, “a unit test is a procedure
used to validate that a particular module of
source code is working properly”
Method that exercises another piece of code
and
d checks
h k results
lt and
d object
bj t state
t t using
i
assertions
28
What is Test Driven Development?
z
Way of developing code so that you always
have proof that something is working
z
z
– Code that validates other code
– Small chunks of “is it working?”
z
S ll chunks
Small
h k = Unit
U it Tests
T t
z
Kent Beck (“Test-Driven Development”,
Addison-Wesley) says “Never write a single
line of code unless you have a failing
automated test.”
Get an idea for what you want to develop
Brainstorm success and failure scenarios
– These become your tests
29
How to begin?
30
5
Basic structure of a Visual Studio
unit test
The Process
z
From William Wake’s “Extreme Programming
Explored” (Addison-Wesley)
1. Write the test code
2. Compile the test code Æ Fails because there’s no
implementation
3. Implement just enough to compile
4. Run the test Æ Fails
z
Microsoft.VisualStudio.QualityTools.UnitTestFrame
work
z
Test fixture (aka Test Class)
– Marked with the [TestClass] attribute
– Collection of unit test methods
– Needs a parameter-less constructor
z
5. Implement enough code to make the test pass
6. Run the test Æ Pass
Unit test method
– Marked with the [TestMethod] attribute
– Must be public
7. Refactor for clarity and to eliminate duplication
– Must return void
– No method parameters
8. Repeat
31
32
Demo
z
z
Using the AdventureWorks database
Write a test to create a new person
Why Use TDD?
z
High-quality code with fewer bugs
z
Using the “test first” method means you think
out how your code will work Æ ~up-front
design
Less time spent in the debugger
– The bugs you find are easier to diagnose
z
– Do you remember what it was like when you first
started doing OO code?
z
– Easy to maintain & change Æ Refactoring
– Code is exercised and the unit tests document how
the developer intended it to be used Æ Self
documenting
33
Why you shouldn’t test: Excuses
z
“It takes too much time”
34
z
– Wrong: it does take time to create/run unit tests, but it
will reduce the overall time spent fixing defects in the
code
– Code that’s well-tested can be modified / extended very
easily
il
– Code that’s not tested can’t be reliably built-onto
– Unit Tests let you pay-as-you-go rather than try to
test/debug/fix more complex interrelated code much
later
– “Dude, pay now or pay later. It’s up to you.”
And because you have tests that say when
something works…
Here’s what takes too much time:
– Time spent debugging (your own or other’s code)?
– Time spent fixing defects in code that previously was
assumed to be working
– Time spent isolating a reported bug
z
Time needed to write Unit Tests will only
consume a small amount of the time freed when
you reduce time spent on these
35
6
z
z
“It takes too long to run Unit Tests”
z
– Wrong: you’re supposed to write reliable code
– You can run dozens or hundreds of tests in seconds
– You can always separate out long-running tests
– Until you’ve objectively verified its reliability – and
done so in a way that can be repeated easily – you’ve
not done yyour jjob
“I d
don’t
’t kknow h
how th
the code
d iis supposed
d to
t
behave, so I can’t test it”
z
– If you don’t know how it’s supposed to behave you
shouldn’t be writing it!
“I’m not allowed to run tests on a live
system”
– Wrong: Unit Tests aren’t for testing a live system.
– Unit tests are for testing by developers using your
“I’m being paid to write code, not write tests”
– Wrong: you’re being paid to write dependable,
working code, and not to spend the day debugging it.
– Unit Tests are means to guarantee that your code is
working.
– WHAT?!
z
“It’s not my job: I’m supposed to write code”
– Wrong: most unit tests run very quickly
z
“I can’t afford it”
– Wrong: you can’t afford not to test
– Plus, you can’t perform serious development of .NET
and Windows without MSDN Premium (includes VSTS
37
Do I have to?
z
z
Yes, and you’ll be glad you did.
You’ll thank me when you’re older
More unit test structure
z
z
Assembly setup/teardown
– Executed once per test assembly
– [AssemblyInitialize]
– [AssemblyCleanup]
– As your system gets larger, you’ll be glad you wrote
your tests
z
z
A t
Automated
t d Æ Much
M h easier
i than
th clicking
li ki
through 80 different screens to exercise your
code or re-create a bug
Automated regression testing
Fixture setup/teardown
– Executed once per test fixture
– [ClassInitialize]
– [ClassCleanup]
z
– Since unit tests (ideally) run quickly, as you develop
you can test how your changes affects other people’s
code – not just yours
Test setup/teardown
– Executed for each test
– [TestInitialize]
– [TestCleanup]
39
40
Other unit test attributes
z
[Ignore]
z
[ExpectedException]
Passes if (Abs(expected – actual) < delta)
z
AreSame / AreNotSame
z
IsTrue / IsFalse
IsNull / IsNotNull
IsInstanceOfType / IsNotInstanceOfType
Inconclusive
Fail
– Compares by reference
[DeploymentItem]
– Method attribute
– Specifies a file that should be copied to the test run bin
directory
z
z
z
[Timeout]
– Maximum time in milliseconds the test should run
Use assertions to check return values, object
state to confirm your coding assumptions
AreEqual / AreNotEqual
– Compares by value
– AreEqual() for floats and doubles have an optional
“d lt ”
“delta”
– Used to test error handling
– Test fails if an exception of the expected type has not
been thrown
z
Assert Methods
z
– Class or method attribute
– Causes unit test framework to skip the test or fixture
z
38
z
41
z
42
7
StringAssert Methods
z
z
z
Contains(string, substring)
CollectionAssert Methods
z
AllItemsAreInstancesOfType()
– String contains a substring
z
AllItemsAreNotNull()
– Case-sensitive
z
AllItemsAreUnique()
z
AreEqual() / AreNotEqual()
z
AreEquivalent() / AreNotEquivalent()
StartsWith() / EndsWith()
Matches() / DoesNotMatch()
– No duplicate values (value types) or instances (ref types)
– Same items, # of occurance, same order
– Uses regular expressions
– Same items, same # of occurrences
– Not necessarily the same order
z
Contains() / DoesNotContain()
z
IsSubsetOf() / IsNotSubsetOf()
– All values in collection x exist in collection y
43
Things you can do with your unit
tests
Assert methods and error messages
z
All assertion methods take an error message
z
– Displayed if the assert fails
z
44
z
Code Coverage
Code Profiling
All methods also have an override that takes
a parameterized string
– Same as String.Format()
()
– Assert.AreEqual(
“asdf”, “xyz”,
“Values were not equal at {0}.”,
DateTime.Now);
z
Best practice: provide a descriptive error message
on all asserts
45
Code Coverage
z
Keeps track of which lines of code are run
z
Shows you which code your tests aren’t
exercising
46
Code Coverage Demo
– More importantly, NOT run
– Like
k plaque
l
dye
d tablets
bl
& brushing
b h
your teeth
h
– Shows you all the spots you missed
z
Helps find unused code
– Especially after refactoring
– “Dead” code
47
48
8
Code Profiling
z
z
z
Similar to code coverage
Shows you the relative effort expended in
different parts of your code
Profiling Modes
Why profile a unit test?
z
Why profile a unit test? Why not just profile
your app?
z
Unit tests give you a predictable, repeatable
usage of your app
– Run your test
– Sampling
– Look at the profiling output
Overview mode Æ use to find performance
problems
Profiler gathers broad info at intervals
– Refactor for performance
– Rinse, repeat
– Instrumentation
z
Specific mode Æ use to dig into performance
problems
z
Microsoft recommends profiling “Release”
builds
Since you have your tests, you’ll know if your
performance refactoring just broke something
else
49
50
Code Profiling Demo
Best Practices
z
z
Write tests before writing code implementation
Make tests autonomous
– Avoid creating dependencies between tests
– Tests should not have to run in a particular order
z
One test fixture ([
([TestClass])
]) per
p class
– Simplifies test organization
– Easier to choose where to locate each test
z
Avoid creating machine-dependent tests
z
Use mock objects to test interfaces
– E.g., tests dependent on a particular directory path
– Objects in test project that implement an interface to
test required functionality
z
51
Best Practice: Design For
Testability
z
Get as much code as possible out of the user
interface
z
z
G what’s
Get
h ’ changed
h
d since
i
you started
d working
ki
– Rebuild
Makes sure that what you’ve changed / written still
compiles when combined with other people’s code
Mocks
– Retest by running the unit tests
– Lightweight, dummy objects that do exactly what you
want without complex setup
z
Is possible, make a method “protected” rather
than private
Avoid “broken” builds
When you’re doing TDD with a team, before
you check in your changes
– Do a “get latest”
Interfaces
– As much as possible, code against interfaces rather
than concrete classes
– Makes it easier to create mock objects
z
52
Best Practice: Team Dev, TDD, &
Source Control
z
– N-Tier Design
– Great for re-use
Verify (and re-verify) that all tests run
successfully before creating a new test
Makes sure that your tests and everyone else’s
tests still pass when combined with other people’s
code
– Check in your code
53
54
9
Best Practice: Bug fixing
z
When bugs are assigned
What makes a good unit test?
z
Exercise your code for success and failure
z
Try to write your tests so that they can run
individually
– Probably be bugs visible from the user interface
z
– Code coverage
Before you fix the bug…
– Write a test to reproduce it
– No particular
l order
d
– The
h test should
h ld fail
f l
z
– No dependencies between tests
Fix the bug using the unit test
– Code until the test passes
z
Database-related tests
– Create your test data as part of the test run
– Run all the other tests to check that the fix didn’t
break other parts of the system
You need data to exercise the “weird” cases and
the only way to be sure you have “weird” data is to
put it there yourself
55
56
Other Test Functionality in VSTS
z
z
Generated Unit Tests
More types of unit tests
– “Regular”
– Data-driven
– Ordered
d d
Generating Tests in VSTS
z
VSTS gives you tools to generate unit tests
for existing code
z
Big Negative: Violates “test first” development
Positive: Helps create tests for legacy code
Positive: Helps create tests for non-public
code
Negative: Not great looking code
z
z
– Web test (VSTS Tester Edition)
z
– Creates VSCodeGenAccessors class for non-public
members
z
Positive: Better than nothing
57
58
Data--Driven unit tests
Data
z
z
Unit test that runs off of a data source
Test executed once for each record the
source
Data--driven test: Structure
Data
z
Structure
– [DataSource()] attribute
– Uses TestContext object
– Accesses the row data via TestContext.DataRow
– 80 records Æ 80 test runs
– 2 million
illi records
d Æ 2 million
illi test runs
– Different data for each run
z
z
Helps separate the test logic from the data
needed to run the test
More runs + more data Æ more confidence in
the test
59
60
10
Data--driven test: Data Sources
Data
z
Any ADO.NET data source
DataSource attribute
z
[DataSource(sourceName)]
z
[DataSource(connStr, tableName)
– Named data source configured in app.config
– SQL Server
– Excel
– Access
z
– OLEDB connection string
– Name of the source table
M t be
Must
b a table
t bl Æ No
N queries
i allowed
ll
d
– Impractical to use a 2 million record table as the
source
z
z
[DataSource(providerName, connStr, tableName,
method)
–
–
–
–
Specified on the test using the [DataSource]
attribute
Provider name (e.g. “System.Data.SqlClient”)
Provider connection string
Source table
method Æ DataAccessMethod enum
Sequential
Random
61
DataSource Configuration in
App.config
62
TestContext class
z
Add “microsoft.visualstudio.testtools”
configuration section handler
z
Abstract class set to the TestContext property
on tests by the testing framework
z
<connectionString> for each connection
Add <dataSources> to
<microsoft.visualstudio.testtools> section for
each named data source
z
Holder for information about the test
z
– DataSource, DataRow
– TestName
– Test directory info
– BeginTimer(timerName) / EndTimer(timerName)
Specify named timers Æ timer stats get stored with
the test run
– AddResultFile(filename)
Include files in the test run results
63
Ordered Tests
z
z
Not really a unit test
Test list composed of other unit tests
64
Dynamic Mock Objects with NMock
z
– Lightweight, dummy objects that do exactly what you
want without complex setup
– Extend other objects or implement an interface
– Appears in the test view as one test
z
z
Arranged to run in a particular order
No initialize or teardown methods
z
NMock
– Open-source utility
– http://www.nmock.org
– Creates classes at runtime that implement an
interface
– Allows you to specify return values and expected
behavior for methods on the interface
65
Mocks
66
11
NMock.DynamicMock
z
DynamicMock mock = new
DynamicMock(System.Type);
z
Expect(methodName)
z
E
ExpectAndReturn(methodName,
A dR
(
h dN
returnValue)
V l )
Designing for UI Testability
– Expects that this method is called once
– Expects this property/method is called Æ returns the
value
z
ExpectAndThrow(methodName, exception)
– Expects a call on this property/method Æ throws the
exception
z
Verify()
– Called at the end of the test
– Checks that all the “expect” methods were called
67
Unit Testing UI’s Overview
z
z
z
z
Review: Why do you care about unit testing?
Why are UI’s so difficult to test?
How do you organize your code for UI
testing?
Disclaimer: I’m a web guy.
Why Use TDD?
z
High-quality code with fewer bugs
z
Using the “test first” method means you think
out how your code will work Æ ~up-front
design
Less time spent in the debugger
– The bugs you find are easier to diagnose
z
– Do you remember what it was like when you first
started doing OO code?
z
And because you have tests that say when
something works…
– Easy to maintain & change Æ Refactoring
– Code is exercised and the unit tests document how
the developer intended it to be used Æ Self
documenting
70
Maximize Your QA Staff
z
You shouldn’t need QA to tell you your code
doesn’t work
z
Unit testing to minimizes the pointless bugs
– “nothing happened”
– “I got an error message” + stack trace
– NullReferenceException
z
z
Not easy to automate the UI testing
Basically, automating button clicks
z
UI’s almost have to be tested by a human
z
– Computers don’t understand the “visual stuff”
– Colors, fonts, etc are hard to unit test for
– “This doesn’t look right” errors
QA should be checking for
– Does meet requirements
– Usability problems
– Visual things (colors, fonts, etc)
z
User Interfaces: The Redheaded
Stepchild of the Unit Testing World
When you get a bug assigned to you it should
add business value
z
The rest is:
– Exercising the application
– Checking that fields have the right data
– Checking field visibility
12
UI Testing Tools Are Out There…
z
z
For Windows forms they’re expensive
For web applications
– Visual Studio Team System Web Tests
z
z
…but they aren’t great
Record paths through your application
Fills in form values
z
Click buttons
Validates
z
Difficult to do test-driven development
z
– NUnitAsp
z
VSTS Web Tests
NUnitAsp
z
z
z
Open source
http://nunitasp.sourceforge.net/
Use helper objects to create code based
representation of your ASPX pages, UI
controls
z
Works ok until you start doing custom
UserControls
z
Downside: you basically re-create your “codebehind” with NUnitAsp objects
Big downside: Hasn’t been updated in a long
while
z
My $0.02
z
z
The Solution.
z
Keep as much logic as possible out of the UI
Poll: Show of hands
z
How many of you think you’ve gotten as
much logic as possible out of your UI’s
already?
Testt th
T
the b
business
i
tier
ti
“Transaction Script” Pattern
z
Another $0.02: I’d bet you could get even
more logic out of your UI’s.
“Domain Model” Pattern
“Service Layer” Pattern
“Model View Controller” Pattern
z
Ok. Maybe. But how?
– Shouldn’t be more than a handful of assignments
– Nothing smart
– Real work is handled by the business tier
z
z
z
z
z
Solve the problem by not solving the problem
Find a way to minimize what you can’t
automate
13
Tiering Up: Keep Logic Out Of The UIs
z
z
Business Object Tier (Domain Model pattern)
Business Façade Tier (Service Layer pattern)
– Create new Business Object methods (Factory
methods)
Interface interfaces
z
Interface represents the fields manipulated
through the UI
z
ASPX Page or Windows Form Implements the
interface
– Interface’s properties wrap UI widgets
– ICustomerDetail.CustomerName
ICustomerDetail CustomerName Æ
– Wrap CRUD operations, abstract away data access
logic
g
– Duplicate name checks
z
z
m_textboxCustomerName.Text
Create an interface to represent each page in
your application
Create Editor Facades as an adapter between
the UI interfaces and the business objects
z
z
z
Editor facade
Why is this more testable?
z
z
Similar to business object facades that wrap
CRUD operations
z
Wrap larger operations that are relevant to
each UI page/screen interface
– InitializeBlank(ICustomerDetail)
i i li
l k( C
il)
– View(ICustomerDetail)
– Save(ICustomerDetail)
z
Since each page implements the interface,
pass the page reference to the Editor facade
Use a “stub” class in your unit test to
represent the UI
Write unit tests to test the functionality of the
editor façade
Avoid business objects Æ favor scalars
z
z
z
z
Each page/screen only has to get/set the
value from interface property into the right
display control
UI does not know anything about business
objects
Doesn’tt know about any details of loading or
Doesn
saving
Doesn’t have to know about validation
All this logic goes into the editor façade and
testable via unit test
Avoid Referencing Business Objects
in the UI “interfaces”
z
ASP.NET
– Easier to write stateless pages (everything is in
ViewState)
– No need to try to re-create complex objects in code
behind in order to save
Code Demo
z
Refactor to UI Interfaces
Populate drop down lists
z
Getting/setting selected value(s) from
z
– Drop down list
– Checkbox list
z
z
Search for a value in the db
Create new / Update existing
14
Questions?
Section 3: Team Projects
z
z
z
z
z
z
z
Similar to a “solution” in Visual Studio
Has a development process (aka
methodology)
Container for all items related to the project
Work Items
Editing with Excel
Customizing Work Items
Supported TFS Development
Processes
Team Project
z
Create a Team Project
Process Templates
z
z
z
MSF for Agile Software Development
MSF for CMMI Process Improvement
Scrum for Team System
– http://www.scrumforteamsystem.com
– TFS process template developed by Conchango
– Work items
– Documents
– Reports
– Builds
– Source Code
87
88
What is a work item?
z
z
z
z
Unit of work tracked by TFS
Agile: Scenario, Bug, Task, Quality Of Service
Requirement, Risk
CMMI: Bug, Change Request, Issue,
Requirement, Review, Risk, Task
Work Item Queries
z
SELECT statement against the work item
database
z
Can be visible to either the whole team or
just individuals
Has “state” (aka status) and state transitions
– e.g. Active Æ Closed
z
Assignable to one person
z
Linkable to other work items
Has history (auditing)
z
89
90
15
Demo
z
z
z
z
z
Create some work items in Team Explorer
Run a work item query
Editing Work Item Templates
z
z
Export results in Excel
Publish changes from Excel
Edit a work item query
Work items are defined via XML
Export / import using witexport.exe /
witimport.exe
92
Demo: Edit a Work Item Template
z
z
Questions?
Add the WITs to source control
Add a field
Section 4: Source Control
z
z
z
z
z
z
z
What is it and why use it?
Set up the repository
Why use source control?
z
z
Minimize / eliminate lost work
Reproducible builds & product state
Why do you care about broken builds?
What
at iss “continuous
co t uous integration”?
teg at o
How do you keep people from breaking the
build?
Branching & Merging
Shelving
96
16
TFS Source Control
z
Real, enterprise-quality source control
Uses SQL Server 2005 as the repository
z
Transactional, atomic
z
TFS Source Control: Features
z
Workspaces
z
Check in / check out
– Area on local disk where you edit files
– Check out marks the beginning of your edits
– Check in commits your changes to the repository
– TFS allows shared check out
z
Changesets
z
Shelving
– Group of changes that happen when you check in
– Similar to check in
– Changes get stored on the server
– Not visible as part of the main project source tree
z
Branching
– Used to manage multiple versions of a product
97
Modifications & Check in’s
z
z
z
All these operations are batched
98
TFS Source Control: Support beyond
VS2005
z
Team Foundation Server MSSCCI Provider
– Available for download from microsoft.com
– Add, Delete
– Moves, Renames
– Modifications
z
Source control only
– Branches / Merges
z
Supports:
– Now on version 1.2
Batch is “sent” at check in
Check in is atomic Æ Changeset
–
–
–
–
–
99
Demo: Add a project to source
control
101
Visual Studio .NET 2003
Visual C++ 6 SP6
Visual Visual Basic 6 SP6
Visual FoxPro 9 SP1
Microsoft Access 2003 SP2
– SQL Server Management Studio
– Sparx Systems Enterprise Architect 6.1
– Sybase PowerBuilder 10.5
T d f SQL S
20
100
Demo: Configure check in rules
102
17
TFS does more than just checkcheck-in
and checkcheck-out
z
Branching & Merging
Branching and merging
z
z
You can specify 3rd-party merge tools
– Tools Æ Options Æ Source Control Æ Visual Studio
Team Foundation Æ File Extensions… Æ Add… Æ
Configure Tool
– Facilitates simultaneous development of multiple
versions of an app
Best Practice: Do not add sources directly to
the root of your Team Project source control
tree
– $/My Team Project/Trunk
– $/My Team Project/Branches
104
TF.exe
The Commands
z
z
z
z
Command-line interface to TFS source control
30+ sub commands
z
z
– Kind of like “net” command in Windows
z
z
Why would you want to use the command
line version?
z
z
1. It’s cool
2. Some things aren’t available through the UI
3. Good for automated operations (builds, etc)
z
z
z
z
z
Add
Branch / Branches
Changeset
Checkin / Checkout
Configure
Delete / Undelete
Dir
Get
History
Label / Labels / Unlabel
Lock
Merge / Merges
z
z
z
z
z
z
z
z
z
z
z
Move
Permission
Properties
Rename
Resolve
Shelve / Unshelve
Status
Undo
View
Workfold
Workspace / Workspaces
105
106
TF.exe Workspaces
Things not easily done through the GUI
z
Find files in TFS by name/wildcard
z
– tf dir
z
z
Find all the files that are checked out or have
pending changes for the whole project
z
– tff status
z
Get particular version of a file by wildcard
z
– tf get
z
Do a preview of “Get Latest”
z
Change the user associated with a workspace
z
z
– tf workspace
107
/format:brief, /format:detailed
/updateUserName – change the network
username associated with workspaces
/updateComputerName – change the name of
the client computer
/server – name of the TFS machine
/owner – who’s workspace
/computer – which computer does the
workspace exist on?
108
18
TF.exe Workspace
z
z
z
z
z
/new – create new workspace
/template -- copy the setup of this workspace
from another workspace
/delete – delete the workspace
/computer – computer that the workspace should
be created on
/comment – workspace comment description
z
z
z
z
z
z
– Comments can also come from a file (@commentFile)
z
z
z
/server – TFS machine that will govern the
workspace (you need this if you access >1 team
server from this computer)
/newname – renames the workspace
/noprompt – hide the dialog box (you’ll want this
on everything)
TF.exe Get
z
z
z
109
z
Available on “branch”, “dir” and “get”
/version
110
Customizing Version Control
z
z
– /version:1234 – by version #
– /version:D10/11/2001 – by date (mm/dd/yyyy)
– /version:C1234
/
– by
b changeset
h
#
– /version:Llabeltext – by label
– /version:T – latest version
– /version:Wworkspacename
Example: get everything for this workspace for
changeset #29
– tf get * /all /version:c29 /recursive /force
TF.exe Switches: /version
z
Gets file(s) from server to workspace
/version
/all – forces get all files
/overwrite – wipes out read-only files that aren’t
checked out
/force – equivalent of /all + /overwrite
/preview – show what would happen but don’t do
it
/recursive
/noprompt – no visual dialog boxes
Create a custom check-in policy
Extend PolicyBase
– Microsoft.TeamFoundation.VersionControl.Client.dll
z
z
Mark class as [Serializable]
PolicyBase.Evaluate() lets you examine
– What’s being checked in
– Associated work items
– Check-in comments
– Other check-in policies
111
Installing the CheckCheck-in Policy
z
z
z
z
Compile
Copy to the server
Go to
HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\
TeamFoundation\SourceControl\Checkin
Policies
Add new “string value”
Policy Gotcha!
z
z
z
Policies are evaluated on the client
Policy DLL must be installed on every
developer’s computer
Server-side policy configs are stored using
binary serialization
– Everyone must have the same version of the policy
DLL
– Value name must be the same as the DLL name
(minus “.dll”)
– Data is the full path to the DLL
19
Demo: Custom Policy
Demo: Static Code Analysis
Extra Demo: Use Custom SCA Rule
to Enforce Variable Naming
Questions?
Visual Studio Team
System
Section 5: Visual Studio Team
Edition for DB Professionals
CIO
PMO
Architect
Tester
Developer
Designer
Project
Manager
Application
Support
Business
Analyst
Operations
20
Visual Studio Team
System
What MSFT Heard from Customers
CIO
PMO

aka. “why did they build it…”

Managing database change is hard….
A rollback means a LONG night
Architect
Team Edition for
Database Professionals
Tester
Development teams can end up working with out-of-date versions
• Expand
E
d to
t database
d t b
teams
t
• Manage Database Change
• Extend Team productivity and
collaboration
Developer
• Integrated quality
DB ProDesigner
Loss of revenue because the release wasn’t
wasn t synchronized

More costly than finding them early
Increased support cost when you break an application from a
database update
Project
Manager

Application
Support
Business
Analyst

Finding errors at the end of the development cycle
Disconnect between development and database teams
Need to be more integrated
Operations
Conceptual Overview

Difficult to manage change to the
schema

Production database is one version of
the truth for data and schema

Database administrator (DBA) doesn’t
have access to changes until he/she has
deploy or reject choice
Production
Database
Management
Studio
Tuning
Monitoring
Schema Changes
Schema
Changes often made to production
database and not rolled back into test
“One Version of the
Truth” for Data and
Schema
Conceptual Overview

Schema change now managed in Visual
Studio Team System and Team
Foundation Server

Production Database is now “One version
of the truth” only for Data

DBA doesn’t have access to changes
until he/she has deploy or reject choice

“One Version of the truth for Schema” is
Under Source Control
Production
Database
Management
Studio
Tuning
Monitoring
“One Version of the
Truth” for Data
“One Version of the Truth”
for Schema
• Offline
• Under Source Control
Changes can be rolled out
in a scheduled, managed
way
Scripts allow
administrators to mange
change updates
Schema
Schema Changes
Creating a Project
Database Projects
•
•
•
•
•
Core concept: offline database development
Simply a series of files collected together into a single
logical collection
The files represent the truth of your schema
Can be included in complete solution
Connects to SCCI providers for versioning such as Team
Foundation Server
Creating a Baseline
21
Offline Development
•
•
•
Import database schema to populate project from
existing database
Changes to schema traditionally have immediate
affect
With offline project nothing changes until you
deploy the change
Establish the project environment
Code Demo
z
z
z
z
z
Create some work items in TFS
Import the northwind schema
Check it in to TFS
Add a new lookup table
Create a post-deployment script
Isolated Iterative Development
Sand
box
SCM
SCM
Sand
box
Sand
box
Check in to
S
Source
Control
DBDev
DBA
Sand
box
• Sync
• Check
Check--out
• Edit/Refactor
• Test
• Check
Check--in
• Work is being
driven
and tracked via
work items
DBDev
DBA
Database
Project
Import schema
Staging
Database
Staging
Database
Production
Database
Production
Database
129
Build Cycle
Can also be
used in a
“Continuous”
build environment
SCM
Daily
Build
Output
130
Deploy the project environment
Test
Database
Get Latest
Daily Build
SCM
Test
Staging
Database
Deploy
Database
Project
Production
Database
131
Sy
ync from Label
DBDev
DBA
DBDev
DBA
Refine deploy script
Build
SQL
Deploy
Script
Verify
Staging
Database
Production
Database
132
22
Benefits of Approach
Managed, project oriented evolution of database
schema
Ensure Stability
Application and database schema can now be
managed together
Work in “isolation”
isolation , deploying only when changes
verified through empirical means
Leverage VSTS work item tracking and process
guidance increases team collaboration and unity
Testing Your System
133
A Rollback Means a LONG Night
What We Can Test
•
•
•
•
Unit testing helps ensure that changes do not break
existing code
•
•
Unit test designer is SQL focused
•
• Work in the language of your choice: Transact-SQL (T-SQL),
Microsoft® Visual Basic®, Microsoft® Visual C#®
•
Builds on existing Team Test Unit Test functionality
•
•
Stored Procedures
Functions
Triggers
Arbitrary SQL
Support at Release to Market (RTM) to automatically
deploy changes to test system and generate data
Deterministic data generation ensures stable test
state
Can test with your application tier because of
common framework
Generate Test Data
with Regular Expressions
Test Data
•
•
•
•
•
To create a solid foundation for testing we support data
generation
Deterministic – always generate the same layout
Matched to your schema and very customizable
Extensible mechanism, build your own generators
Feature: DataGenerator
z
Names:
[A-Z][aeiou][a-z]*
z
Email Addresses:
[a-z0-9]*@[a-z0-9]*\.(com|org|net|co\.uk)
Phone Numbers:
$[0-9]{3}$-[0-9]{3}-[0-9]{4}
z
23
Code Demo
z
z
z
z
Database Projects
Create some test data
Write a stored procedure
Unit test the stored procedure
Managing Change
Managed Change
•
•
•
Changes are local to project
Project can be compared with database
All elements can be managed under version control
• Any SCCI compliant version system
•
Working with the Project
•
•
•
•
Add new elements
Modify existing elements
Delete items
Deploy new or incremental update
Template driven
• Version specific Microsoft® SQL Server™ 2000 or SQL Server™
2005
Refactoring
•
•
Code Demo
Brings power of refactoring to SQL
z
• Cascading change
z
Refactor
Update all dependent objects in database project
• Schema objects, Data generation, Unit Tests, SQL Scripts
•
•
Make an atomic change, see preview
Rename
• Meet corporate standards
• Better express semantic intent – clarity
24
Code Demo:
Do Things The Wrong Way
z
Well…if you must
Modify the production schema
z
Import production changes into offline copy
z
Questions?
Section 6: Team Build
Build/Deploy
•
•
Standard Visual Studio build task
Configurations
• New versus update builds
• Project properties for build
• Schema compare used for build
•
•
•
Pre/Post Deployment scripts
Build results in SQL script file
Deploy
• Deploy via SQL query tool
• Deploy via MSBuild task
• SQLCMD command support
Why do I care?
z
z
z
z
z
z
Builds should be repeatable
Unrepeatable Æ low quality
Automated Æ easy to run
Easy
a y to
o run
u Æ do it more
o often
o
More often Æ continually integrating
Continually integrating Æ you know when it’s
broken
z
z
149
Demo: Create a team build
Create a test list
Create a build with build verification tests
150
25
Structure of your Team Build
z
Team Build directory
z
– Off of root of your source tree
z
Demo: Run the build
z
Run the build
Vote of build quality
TFSBuild.proj
– The build script
z
TFSBuild.rsp
– “Command line” arguments fed to the team build
– Example: /verbosity:diag
z
WorkspaceMapping.xml
– Used by “InitializeWorkspace” to set up source control
152
Demo: How to edit an existing build
z
z
Set up workspace to get the build definition
View, check out, edit, check in
Run tests without test lists
z
z
.vsmdi’s are a pain
Buck Hodges’ Test Tools Task
– http://blogs.msdn.com/buckh
– http://blogs.msdn.com/buckh/attachment/951614.ashx
z
Runs all unit tests in an assembly
153
Modifying your build script to use
the power toy
Deploying the power toy
z
Extract the zip
z
z
Copy
Microsoft.TeamFoundation.PowerToys.
Tasks.QualityTools.dll to
z
z
C:\Program Files\Microsoft Visual Studio 8
\Common7\IDE\PrivateAssemblies\
Copy Microsoft.TeamFoundation.Build.targets to
C:\Program Files\MsBuild\
Microsoft\VisualStudio\v8.0\TeamBuild
Open TeamBuild.proj
Find
<MetaDataFile
Include="$(SolutionRoot)\MyTestLists.vsmdi">
<TestList>All Tests</TestList>
</MetaDataFile>
z
Replace with
<TestContainerInOutput Include=“MyTestAssembly.dll" />
z
To run with code coverage, add
<RunConfigFile>
$(SolutionRoot)\MyTestRunConfig.testrunconfig
</RunConfigFile>
to the first
<PropertyGroup>
in the build script
26
Controlling Builds From The
Command Line
MSBuild Targets
z
1.
2.
3.
4.
5.
6
6.
7.
8.
9.
Think “events”
BeforeEndToEndIteration
AfterEndToEndIteration
BuildNumberOverrideTarget
BeforeClean
AfterClean
BeforeGet
AfterGet
BeforeLabel
AfterLabel
10. BeforeCompile
11. AfterCompile
12. BeforeTest
13. AfterTest
14. BeforeDropBuild
15 AfterDropBuild
15.
16. BeforeOnBuildBreak
17. AfterOnBuildBreak
z
TFSBuild.exe
– start servername teamproject buildname
– stop servername teamproject buildnumber
– delete servername teamproject buildnumber
Desktop Builds
z
Questions?
Run your build script outside of Team Build
Server
– Create and debug your scripts
– Command line
z
z
Does nott d
D
do th
the ““gett llatest”
t t” operation
ti
msbuild TFSBuild.proj
/p:SolutionRoot=“path_to_solution_directory“
– /p – specify property values (separated by semicolon)
– /p:RunTest=false; SolutionRoot=
“path_to_solution_directory“
Agenda
z
z
z
z
z
z
TFS & VSTS Overview
Unit Testing & Test-Driven Development
Team Projects
Source
Sou
ce Co
Control
to
Database Development with VSTS
TFS Build System
About the speaker
z
– Email: benday@benday.com
– Web: http://www.benday.com
p //
y
– Blog: http://blog.benday.com
z
Trainer, Richard Hale Shaw Group
– http://www.richardhaleshawgroup.com
– Visual Studio Team System, Team Foundation Server
z
z
Owner, Benjamin Day Consulting, Inc.
Microsoft MVP for C#
Leader of Beantown.NET INETA User Group
27