Visual Studio 2010 Unit Testing - Benday

Transcription

Testing In
Visual Studio 2010
Benjamin Day
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
1
Benjamin Day
• Consultant, Coach, Trainer
• Scrum.org Classes
– Professional Scrum Developer (PSD)
– Professional Scrum Foundations (PSF)
•
•
•
•
TechEd, VSLive, DevTeach, O’Reilly OSCON
Visual Studio Magazine, Redmond Developer News
Microsoft MVP for Visual Studio ALM
Team Foundation Server, TDD, Testing Best Practices,
Silverlight, Windows Azure
• http://blog.benday.com
• benday@benday.com
2
Agenda
•
•
•
•
•
•
•
•
•
What is Test Driven Development?
How do you do Test Driven Development in VS?
Why Test Driven Development?
How much is enough?
Code Coverage
Code Profiling
Data-driven Tests
Ordered tests
Dynamic Mocks using RhinoMocks
• Design for Testability
• User Interface Testing
3
What is Test Driven Development?
• Way of developing code so that you always
have proof that something is working
– Code that validates other code
– Small chunks of “is it working?”
• Small chunks = Unit Tests
• Kent Beck (“Test-Driven Development”,
Addison-Wesley) says “Never write a single
line of code unless you have a failing
automated test.”
4
What is a Unit Test?
• 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 checks results and object state using
assertions
5
How to begin?
• Get an idea for what you want to develop
• Brainstorm success and failure scenarios
– These become your tests
6
The Process
•
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
5. Implement enough code to make the test pass
6. Run the test  Pass
7. Refactor for clarity and to eliminate duplication
8. Repeat
7
Structure of a Unit Test
• Arrange
– Set up the System Under Test (SUT)
• Act
– Run the operation(s)
• Assert
– Verify that it worked
8
SO, HOW DO I DO TDD IN
VISUAL STUDIO 2010?
9
Basic structure of a Visual Studio unit
test
• Microsoft.VisualStudio.QualityTools.UnitTestFramework
• Test fixture (aka Test Class)
– Marked with the [TestClass] attribute
– Collection of unit test methods
– Needs a parameter-less constructor
• Unit test method
–
–
–
–
Marked with the [TestMethod] attribute
Must be public
Must return void
No method parameters
10
Demo
• Using the AdventureWorks database
• Write a test to create a new person
11
Why Use TDD?
• High-quality code with fewer bugs
– The bugs you find are easier to diagnose
• Using the “test first” method means you think out how
your code will work  ~up-front design
• Less time spent in the debugger
– Do you remember what it was like when you first started
doing OO code?
• 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
12
Why you shouldn’t test: Excuses
• “It takes too much time”
– 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
– 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
• Pay now or pay later.
• 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
• Time needed to write Unit Tests will only consume a small amount
of the time freed when you reduce time spent on these
13
• “It takes too long to run Unit Tests”
– Wrong: most unit tests run very quickly
– You can run dozens or hundreds of tests in seconds
– You can always separate out long-running tests
• “I don’t know how the code is supposed to behave, so I
can’t test it”
– WHAT?!
– 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 own database
and mock objects.
14
• “It’s not my job: I’m supposed to write code”
– Wrong: you’re supposed to write reliable code
– Until you’ve objectively verified its reliability – and done so
in a way that can be repeated easily – you’ve not done
your job
• “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.
• “I can’t afford it”
– Wrong: you can’t afford not to test
15
Do I have to?
• Yes, and you’ll be glad you did.
• You’ll thank me when you’re older
– As your system gets larger, you’ll be glad you wrote
your tests
• Automated  Much easier than clicking through
80 different screens to exercise your code or recreate a bug
• Automated regression testing
– Since unit tests (ideally) run quickly, as you develop
you can test how your changes affects other people’s
code – not just yours
16
More unit test structure
• Assembly setup/teardown
– Executed once per test assembly
– [AssemblyInitialize]
– [AssemblyCleanup]
• Fixture setup/teardown
– Executed once per test fixture
– [ClassInitialize]
– [ClassCleanup]
• Test setup/teardown
– Executed for each test
– [TestInitialize]
– [TestCleanup]
17
Other unit test attributes
• [Ignore]
– Class or method attribute
– Causes unit test framework to skip the test or fixture
• [ExpectedException]
– Method attribute
– Used to test error handling
– Test fails if an exception of the expected type has not been thrown
• [DeploymentItem]
– Specifies a file that should be copied to the test run bin directory
• [Timeout]
– Maximum time in milliseconds the test should run
– Use this for Quality Of Service tests
18
Assert Methods
• 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 “delta”
• Passes if (Abs(expected – actual) < delta)
• AreSame / AreNotSame
– Compares by reference
•
•
•
•
•
IsTrue / IsFalse
IsNull / IsNotNull
IsInstanceOfType / IsNotInstanceOfType
Inconclusive
Fail
19
StringAssert Methods
• Contains(string, substring)
– String contains a substring
– Case-sensitive
• StartsWith() / EndsWith()
• Matches() / DoesNotMatch()
– Uses regular expressions
20
CollectionAssert Methods
• AllItemsAreInstancesOfType()
• AllItemsAreNotNull()
• AllItemsAreUnique()
– No duplicate values (value types) or instances (ref types)
• AreEqual() / AreNotEqual()
– Same items, # of occurance, same order
• AreEquivalent() / AreNotEquivalent()
– Same items, same # of occurrences
– Not necessarily the same order
• Contains() / DoesNotContain()
• IsSubsetOf() / IsNotSubsetOf()
– All values in collection x exist in collection y
21
Assert methods and error messages
• All assertion methods take an error message
– Displayed if the assert fails
• 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);
• Best practice: provide a descriptive error message on all
asserts
22
Best Practice:
Create a Unit Test Base Class
• Create a class called UnitTestBase
• You’ll want it eventually
• Give you a place to hook in to events
– Use Template Method Pattern
23
THINGS YOU CAN DO WITH YOUR
UNIT TESTS
24
Things you can do with your unit tests
• Code Coverage
• Code Profiling
25
Code Coverage
• Keeps track of which lines of code are run
– More importantly, NOT run
• Shows you which code your tests aren’t
exercising
– Like plaque dye tablets & brushing your teeth
– Shows you all the spots you missed
• Helps find unused code
– Especially after refactoring
– “Dead” code
26
Code Coverage Demo
27
What is the right amount of coverage?
• 100%? 90%? 75%?
• It depends.
28
100% Code Coverage
• "Just because you have 100% code coverage
doesn't mean that your code works. It only
means that you've executed every line."
- Scott Hanselman (Hanselminutes interview with Scott Bellware)
29
What’s the right amount?
• Visual Studio team requires >=75% before
merge to $\Main
• Things to decide:
– What’s good coverage vs. bad coverage?
– Is there anything that must be covered?
– What do you do about auto-generated code?
30
Remember to test failures.
• Don’t test for only success
• Input validation
– Pass in null values
– Pass in out of range values
– Helps detect coding errors
• Exception cases
– Helps to detect and handle runtime/user errors
– Security code
– Business logic violations
31
My $0.02: Auto-generated Code
• Examples:
– Typed Dataset
– LINQ to SQL Data Context
•
•
•
•
Lots of stuff that isn’t used by your app
You have no control over the code
Skip it.
If you can, put it in it’s own assembly.
– Don’t run coverage
32
Good coverage vs. Bad Coverage
• Well, maybe not bad coverage
– Useless or low value coverage
• Bad coverage
– Cover every line and every “if” clause individually
– Brute force  zillions of tests
– Takes forever. What’s the point?
• Good coverage
– Great coverage by doing it organically
– Targeted tests that add value
33
You can always add more later.
• I like balance.
• Track your code coverage metrics over time.
– Automated builds?
– Watch for trends.
• If you have systems with a lot of bugs, write
some more tests.
• When you get a bug, create a test first to
recreate the bug.
34
Downside of adding more later
• You’re writing the tests after the code
• Risk: Violates Test-First
• You’ll tend to write tests directly at the code
– Are you making assumptions that won’t track with
real life?
– Do you own the code or does the code own you?
• You really should be asking yourself why your
coverage was low in the first place.
35
Why was coverage low in the
first place?
• Test-First Development helps a lot
– Harder to let the business-tier code get away from you
• Is there a pattern to what you’re missing?
–
–
–
–
Input validation?
Exception handling?
Private methods?
Conditional paths?
• If you aren’t covering it how did it get there in the
first place? Are you sure it isn’t dead code?
36
Code Profiling
• Similar to code coverage
• Shows you the relative effort expended in
different parts of your code
• Profiling Modes
– Sampling
• Overview mode  use to find performance problems
• Profiler gathers broad info at intervals
– Instrumentation
• Specific mode  use to dig into performance problems
• Microsoft recommends profiling “Release” builds
37
Why profile a unit test?
• Why profile a unit test? Why not just profile your
app?
• Unit tests give you a predictable, repeatable
usage of your app
–
–
–
–
Run your test
Look at the profiling output
Refactor for performance
Rinse, repeat
• Since you have your tests, you’ll know if your
performance refactoring just broke something
else
38
Code Profiling Demo
39
TESTING NON-PUBLIC METHODS
40
What if you want to test a
private method?
• Can’t reference the method in code
– Won’t compile
• There are work arounds
• Why do you want to test it in the first place?
41
Why use private methods?
•
•
•
•
•
It’s Object-Oriented Programming 101
Keeps code organized
Avoids duplication within the class
Simplifies refactoring
Simpler interface
– Easier to understand
– Easier re-use
42
Private method testing
• Pro:
– More focused tests
– Ensures coverage of important logic
• Con:
–
–
–
–
Object orientation: it’s private for a reason
Private methods help keep code clean
Covered by other tests already
Introduces “coupling” between tests and private
implementation  refactoring problems
– If you call the private method, does it put your object
in a weird state?
43
Why is it private?
• Remember it’s all about balance
• Could you make the method “protected”?
• Could you move it to a utility class?
– Is the method really related to just this class?
– How hard would it be to refactor it into a utility class?
• The answer to these questions could be “no.”
– Don’t go crazy trying to make it testable.
– Remember you’ll have to maintain this thing.
– There are work arounds.
44
Work arounds
• Make it “protected”
– Create a tester class that extends from the class
you want to test
• Use reflection
– Not compile time safe
• Use a Visual Studio Private Accessor
– Uses reflection
– Not compile time safe
45
Code Demo: Use Protection
• (Ok. You’re all supposed to laugh now.)
• Test a “protected” method
• Create a tester class
46
Code Demo: Private Accessor
• Test a private method
47
My $0.02
• Favor “protected” over reflection
48
SOME BEST PRACTICES
49
Best Practices
• Write tests before writing code implementation
• Make tests autonomous
– Avoid creating dependencies between tests
– Tests should not have to run in a particular order
• One test fixture ([TestClass]) per class
– Simplifies test organization
– Easier to choose where to locate each test
50
Best Practices
• Avoid creating machine-dependent tests
– E.g., tests dependent on a particular directory path
• Use mock objects to test interfaces
– Objects in test project that implement an interface to test
required functionality
• Verify (and re-verify) that all tests run successfully
before creating a new test
• Provide a descriptive error message on all asserts
51
Best Practice: Design For Testability
• Get as much code as possible out of the user interface
– N-Tier Design
– Great for re-use
• Interfaces
– As much as possible, code against interfaces rather than
concrete classes
– Makes it easier to create mock objects
• Mocks
– Lightweight, dummy objects that do exactly what you want
without complex setup
• Is possible, make a method “protected” rather than
private
52
Best Practice: Team Dev, TDD, &
Source Control
• Avoid “broken” builds
• When you’re doing TDD with a team, before you
check in your changes
– Do a “get latest”
• Get what’s changed since you started working
– Rebuild
• Makes sure that what you’ve changed / written still compiles
when combined with other people’s code
– Retest by running the unit tests
• Makes sure that your tests and everyone else’s tests still
pass when combined with other people’s code
– Check in your code
53
Best Practice: Bug fixing
• When bugs are assigned
– Probably be bugs visible from the user interface
• Before you fix the bug…
– Write a test to reproduce it
– The test should fail
• Fix the bug using the unit test
– Code until the test passes
– Run all the other tests to check that the fix didn’t
break other parts of the system
54
What makes a good unit test?
• Exercise your code for success and failure
– Code coverage
• Try to write your tests so that they can run
individually
– No particular order
– No dependencies between tests
• Database-related tests
– Create your test data as part of the test run
• 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
Other Test Functionality in VS2010
• Generated Unit Tests
• More types of unit tests
– “Regular”
– Data-driven
– Ordered
– Web Performance test
– Load Test
– Coded UI Tests
– Database Unit Tests
56
Generating Tests in VS
• VS gives you tools to generate unit tests for existing
code
• 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
– Creates VSCodeGenAccessors class for non-public
members
• Positive: Better than nothing
• Try to avoid generated tests whenever possible
57
Demo: Test a non-public method
• This demo will show 3 ways to test the same method
• Version 1: Generate
– Creates “Private Accessors” in VSCodeGenAccessor.cs
• Generated utility code for accessing non-public methods
• Not type-safe
• Uses reflection
• Version 2: By hand, using PrivateObject
– Cleaner code
– Not type-safe
• Version 3: Using Inheritance
– Type-safe
– Compile-time checking
58
Data-Driven unit tests
• Unit test that runs off of a data source
• Test executed once for each record the source
– 80 records  80 test runs
– 2 million records  2 million test runs
– Different data for each run
• Helps separate the test logic from the data
needed to run the test
• More runs + more data  more confidence in
the test
59
Data-driven test: Structure
• Structure
– [DataSource()] attribute
– Uses TestContext object
– Accesses the row data via TestContext.DataRow
60
Data-driven test: Data Sources
• ADO.NET data source
– SQL Server
– Excel
– Access
• File-based
– XML
– Comma-separated (CSV)
• Must be a table  No queries allowed
– Impractical to use a 2 million record table as the source
• Specified on the test using the [DataSource] attribute
61
DataSource attribute
• [DataSource(sourceName)]
– Named data source configured in app.config
• [DataSource(connStr, tableName)
– OLEDB connection string
– Name of the source table
• [DataSource(providerName, connStr, tableName, method)
–
–
–
–
Provider name (e.g. “System.Data.SqlClient”)
Provider connection string
Source table
method  DataAccessMethod enum
• Sequential
• Random
62
DataSource Configuration in
App.config
• Add “microsoft.visualstudio.testtools”
configuration section handler
• <connectionString> for each connection
• Add <dataSources> to
<microsoft.visualstudio.testtools> section for
each named data source
63
TestContext class
• Abstract class set to the TestContext property on
tests by the testing framework
• Holder for information about the test
–
–
–
–
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
64
Ordered Tests
• Not really a unit test
• Test list composed of other unit tests
– Appears in the test view as one test
• Arranged to run in a particular order
• No initialize or teardown methods
65
Demo: Ordered Test
66
PROBLEMS & SOLUTIONS
Testing Problems
• Extra code just for the sake of the test
• Code coverage on exception handling
• Tendency toward end-to-end integration tests
– Databases
– WCF & Services
– Big back-end systems
• Unit testing UIs
Testing Solutions
•
•
•
•
•
•
Mocks, Stubs, and Mocking Frameworks
Interface-driven coding
Factory Pattern and/or IoC Frameworks
Repository Pattern
Model-View-Presenter (MVP) Pattern
Model-View-Controller (MVC) Pattern
Mocks vs Stubs vs
Dummies vs Fakes
• Martin Fowler
http://martinfowler.com/articles/
mocksArentStubs.html
• Dummy = passed but not used
• Fake = “shortcut” implementation
• Stub = Only pretends to work, returns predefined answer
• Mock = Used to test expectations, requires
verification at the end of test
RhinoMocks
• Dynamic Mocking Framework
• By Ayende Rahien
http://ayende.com/projects/rhino-mocks.aspx
• Free under the BSD license
RhinoMocks Primer
• MockRepository
– Owns the mocking session
• StrictMock<T>()  Call order sensitive
• DynamicMock<T>()  Ignores call order
• Stub<T>() 
– Ignores Order
– Create get/set properties automatically
• ReplayAll()
– Marks start of the testing
• MockRepository.Validate() or ValidateAll()
Demo 1: Stub With RhinoMocks
Demo 2: Test Exception Handling
• Look at some existing code
• Refactor for testability
• Use RhinoMocks to trigger the exception
handler
Avoid End-to-End Integration Tests
Does a good test…
• …really have to write all the way to the
database?
• …really have to have a running WCF service on
the other end of that call?
• …really need to make a call to the mainframe?
The Repository Pattern
• “Mediates between the domain and data
mapping layers using a collection-like interface
for accessing domain objects.”
– http://martinfowler.com/eaaCatalog/repository.ht
ml
• Encapsulates the logic of getting things saved
and retrieved
Person Repository
Demo 3: Repository Pattern
• Simplify database (or web service) unit test
with a repository
DESIGNING FOR UI TESTABILITY
79
User Interfaces: The Redheaded
Stepchild of the Unit Testing World
• Not easy to automate the UI testing
• Basically, automating button clicks
• UI’s almost have to be tested by a human
– Computers don’t understand the “visual stuff”
– Colors, fonts, etc are hard to unit test for
– “This doesn’t look right” errors
• The rest is:
– Exercising the application
– Checking that fields have the right data
– Checking field visibility
Maximize Your QA Staff
• You shouldn’t need QA to tell you your code doesn’t
work
• Unit testing to minimizes the pointless bugs
– “nothing happened”
– “I got an error message” + stack trace
– NullReferenceException
• QA should be checking for
– Does meet requirements
– Usability problems
– Visual things (colors, fonts, etc)
• When you get a bug assigned to you it should add
business value
How would you test this?
What is Design For Testability?
• Build it so you can test it.
How would you test this?
Do you have to take the
plane up for a spin?
http://www.flickr.com/photos/ericejohnson/4427453880/
UI Testing Tools Are Out There…
• For Windows forms they’re expensive
• For web applications
– Visual Studio Web Tests
– NUnitAsp
• Not 100% awesome.
Web Tests
•
•
•
•
Record paths through your application
Fills in form values
Click buttons
Validates
• Difficult to do test-driven development
My $0.02
• Solve the problem by not solving the problem
• Find a way to minimize what you can’t
automate
The Solution.
• Keep as much logic as possible out of the UI
– Shouldn’t be more than a handful of assignments
– Nothing smart
– Real work is handled by the business tier
•
•
•
•
•
•
Test the business tier
“Transaction Script” Pattern
“Domain Model” Pattern
“Service Layer” Pattern
“Model View Presenter” Pattern
“Model View Controller” Pattern
Service Layer Pattern
“Defines an application’s boundary
with a layer of services that
establishes a set of available
operations and coordinates the
application’s response in each
operation.”
-Randy Stafford
From “Patterns Of Enterprise Application Architecture”
by Martin Fowler, Randy Stafford, et al.
Chapter 9
Model View * Patterns
• Help model user interface interaction with “business” tier
• Model View Controller (MVC)
• Model View Presenter (MVP)
– Variation of MVC
– Presenter is specific to the View
• Model View ViewModel (MVVM)
– WPF, Silverlight, Windows Phone 7
• Model = Business Object
• View = User Interface
– Probably an interface
• Controller = Presentation logic
– Makes decisions about what to do & show
89
Model View Controller (MVC)
90
Model View Presenter (MVP)
MVC vs. MVP
• In MVC, view events are handled by the
Controller
• In MVP, view events are handled by the View
and are forwarded to the Presenter for
processing
– Think postbacks & code behind
The Common Tiers
• Presentation tier
–
–
–
–
–
ASP.NET
Windows Forms
WPF
WCF Service
The “View” of MVP
• Presenter Tier
– Handles the "conversation"
between the presentation tier
implementation and the
business tier
– Defines the “View” Interfaces
– “Presenter” in MVP
• Business tier
– Business object interfaces
– Business objects
• The “Model” in MVP
– Business facades
• Manipulate business objects
• Handle requests for CRUD
operations
• Data Access Tier
• Data Storage Tier
– SQL Server
Tiering Up: Keep Logic Out Of The UIs
• Business Object Tier (Domain Model pattern)
• Business Façade Tier (Service Layer pattern)
– Create new Business Object methods (Factory
methods)
– Wrap CRUD operations, abstract away data access
logic
– Duplicate name checks
• Create an interface to represent each page in
your application
• Create Editor Facades as an adapter between the
UI interfaces and the business objects
Copyright © 2007, Benjamin Day
www.benday.com
Consulting, Inc.
95
View interfaces
• Interface represents the fields manipulated
through the UI
• ASPX Page or Windows Form Implements the
interface
– Interface’s properties wrap UI widgets
– ICustomerDetail.CustomerName 
m_textboxCustomerName.Text
• Use a stub represent the UI
• Write unit tests to test the functionality of the
presenter
• Avoid business objects  favor scalars
The Presenter
• Service Layer Pattern
• Wrap larger operations that are relevant to
each UI page/screen interface
– InitializeBlank(ICustomerDetail)
– View(ICustomerDetail)
– Save(ICustomerDetail)
• Since each page implements the interface,
pass the page reference to the facade
Designing the UI for Testability
PersonDetailView.aspx
Why is this more testable?
• 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’t know about any details of loading or 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”
• 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
• Refactor to UI Interfaces
• Populate drop down lists
• Getting/setting selected value(s) from
– Drop down list
– Checkbox list
• Search for a value in the db
• Create new / Update existing
MODEL-VIEW-VIEWMODEL
103
Agenda
• My assumptions
• Super-fast overview
– Model-View-ViewModel (MVVM)
– Unit testing
• How to build stuff and test stuff.
Assumptions
• Automated tests are required for “done”
• Unit tests are written by developers.
• QA testing is different from developer testing.
• MVVM in Silverlight is harder than WPF
– (My demos will be in Silverlight.)
Design for testability?
• Way of architecting your application
• Easy to write & run automated tests
Things that need to be architected.
• Requirement: design for testability
• Requirement: testability in isolation
– They call them unit tests for a reason.
– Helps to remember Single Responsibility Principle
(SRP)
• In Silverlight, figure out async first.
– Not planning for async will crush SRP.
SOLID Principles of Class Design
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Principle
Purpose
Single Responsibility Principle A class should have one, and only one, reason
to change.
Open Closed Principle
You should be able to extend a class’s behavior
without modifying it.
Liskov Substitution Principle
Derived classes must be substitutable for their
base classes.
Interface Segregation
Principle
Make fine grained interfaces that are client
specific.
Dependency Inversion
Principle
Depend on abstractions, not on concretions.
Single Responsibility Principle
•
http://tinyurl.com/ahap3j
• Posters by
Derick Bailey
Things that need to be tested.
Goal: test your application without running the UI
• ComboBox / ListBox
– Population of lists
– Selection logic
• Field-based logic
– Value, Visibility, Validation
– Dependencies between fields
• MessageBoxes
– Alerts and exceptions
• ProgressBar logic
• Model to Data Access
• ViewModel to Model
Overview of unit testing.
What is a Unit Test?
• Piece of code that verifies that another piece
of code
• Test code verifies application code
Why Write Unit Tests?
• High-quality code
– Fewer bugs
– Clean design
– Clean code
• Professional Responsibility
– Proof that your code works
– Notification when your code is broken
– Quality focus throughout the development cycle
• Side Effects
– Code is easier to maintain, refactor
– Self-documenting
Plan for testability?
• If you build it, it needs to be tested.
• If you can test it with an automated test, it’s
better.
• When you build, think of how to test it.
• The architecture changes when you think about
how to test.
• It is important to remember the
“Single Responsibility Principle”
So what is this MVVM thing?
Overview of MVVM.
What is MVVM?
•
•
•
•
Model-View-ViewModel
User interface interaction design pattern
Cousin of Model-View-Controller (MVC)
Enabled by data binding in WPF, Silverlight,
WP7
Why use MVVM?
• …or MVC or MVP?
• Keep code organized
• Separate UI implementation from the logic
• Keep code out of the “code behind”
(*.xaml.cs)
– Hint: this enables Design for Testability
Our “To Do” list
• Architect the Silverlight Async solution
• Re-usable fields
– Values, Visibility, and Validation
• List-based fields
– ComboBox and ListBox
•
•
•
•
MessageBoxes
ProgressBars
ViewModel to Model
Model to Data Access
Tip: If you’re writing Silverlight,
figure out your async solution early.
Network traffic in Silverlight
• It has to be async.
• If it isn’t, the UI thread locks…forever.
My initial client-side architecture.
My architecture after Async WCF
beat me up and ate my lunch.
Async Kills
• Your Repository methods can’t return populated
objects
 must return void
• Exception handling is hard
– Work happens on a different thread
– Exceptions can’t “bubble up” the stack
• You could have your *.xaml.cs handle the
callbacks
– Ugly
– Violates “separation of concerns”
– Not very testable
Longer discussion of Silverlight async
• http://blog.benday.com/archive/2010/12/24/23300.aspx
•
•
•
•
MessageBoxes
ProgressBars
ViewModel to Model
Primitive Obsession in your
ViewModel.
Primitive Obsession
• James Shore’s
“Primitive Obsession”
– Too many plain scalar values
– Phone number isn’t really
just a string
– http://www.jamesshore.com/Blog/
• Validation in the get / set properties is ok but
is phone number validation really the
responsibility of the Person class?
Coarse-Grained vs. Fine-Grained
Object Model
• James Shore blog entry talks about
Responsibilities
– Fine-grained = More object-oriented
– Data and properties are split into actual
responsibilities
• I’m concerned about
– Responsibilities
– Code Duplication
– Simplicity
ViewModelField<T>
• Provides common
functionality for a
property on a
ViewModel
With & Without ViewModelField<T>
Are your ViewModel properties
Coarse or Fine?
• Fine-grained gives you room to grow
• ViewModelField<T>
• Create custom controls that know how to talk
to your ViewModelFields
– Simplified binding expressions
• Add features later
– Field validation later
– Security
Demo
VIEWMODELFIELD<T>
Demo
COMBOBOX & LISTBOX
Demo
MESSAGE BOXES
Demo
PROGRESS BARS
•
•
•
•
MessageBoxes
ProgressBars
ViewModel to Model
Focus your testing on stuff that
tends to be buggy.
Calls to data access are buggy.
• The goal: Data access should take/return Model objects.
• Databases
– ADO.NET objects don’t look like your Model
– Make the db call, convert the data to Models
– Take the Model, convert it to a db call
• WCF Services
– Service Reference classes *are not* your model
– Make a WCF call, convert the data to Models
– Take the Model, make a WCF call
• This stuff is always buggy.
Repository & Adapter Patterns
are your friend
What is Repository?
The Repository Pattern
• “Mediates between the domain and data
mapping layers using a collection-like interface
for accessing domain objects.”
– http://martinfowler.com/eaaCatalog/repository.html
• Encapsulates the logic of getting things saved
and retrieved
Synchronous Repository
Synchronous SQL Server & WCF
A Big Picture
What is Adapter?
Adapter Pattern
• “…converts the interface of a class into
another interface the clients expect. Adapter
lets classes work together that couldn’t
otherwise because of incompatible
interfaces.”
• from “Head First Design Patterns”
by Elisabeth & Eric Freeman
My version of Adapter Pattern
• Take object of Type A and convert it in to
object of Type B
Why are these patterns your friend?
• Help focus your mind
• Better design
• Help contain bugs
– These conversions to/from will be buggy
• Help localize change
– Service endpoint designs will change often
• Unit test the conversions separately
– (Remember it’s a “unit” test.)
Keep the Adapt separated from
the Retrieve
• Two classes
– Repository knows how to talk to the WCF service
– Adapter knows how to turn the Service Reference
types into Models
• Single Responsibility Principle (SRP)
demo
REPOSITORY & ADAPTER
•
•
•
•
MessageBoxes
ProgressBars
ViewModel to Model
No shortcuts: Keep your ViewModels
& Models separate.
No shortcuts: Keep your ViewModels
& Models separate.
• It will be tempting to have your
Repository/Adapter layer create ViewModels
– (Don’t.)
• There’s a reason why it’s called
Model-View-ViewModel
Why keep Model and ViewModel
separated?
• ViewModel is a user interface design
• Model is the state of your application
– aka. “Domain Model” pattern
• ViewModel advocates for the UI
– 1-to-1 between a ViewModel and a *.xaml file
– Might reference multiple Models
• Don’t have the ViewModel fields directly
update the Model.
It’s all about the Cancel button.
• If you’re “two way” data bound,
How do you undo?
Cancel: ViewModel wraps Model
• ViewModel populates
itself from the Model
• User edits the screen,
ViewModel gets updated
• Model doesn’t get changed until Save button
is clicked.
• Model is The Boss.
demo
VIEWMODEL TO MODEL
ADAPTER
Summary: Our “To Do” list
•
•
•
•
MessageBoxes
ProgressBars
ViewModel to Model
Other Resources
• http://tinyurl.com/3d2soe8
Other Resources
• http://tinyurl.com/ln248h
Other Resources
• http://tinyurl.com/3pf8vxd
(Web Performance Testing,
Load Testing, &
Code Profiling content is in
WebLoadTests2010.pptx)
169
170

Visual Studio 2010 Unit Testing - Benday

Transcription

Similar documents

Lichtenstein Handout

$25.00 OFF

a boutique consulting firm

Karmak Business Consulting brings value to your company. Our

Profil englisch neu logo

GAP INC. AND F J BENJAMIN ANNOUNCE FIRST FRANCHISE

Exploring the ARUCC PCCAT Transcript and Transfer Guide

Global Presence Why SAFIRA Partners

DS Project Sheet - Le Cirque