Transcript Visual Studio Team System & Team Foundation Server

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
• [email protected]
Copyright © 2013, Benjamin Day Consulting, Inc. www.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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.”
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
5
How to begin?
• Get an idea for what you want to develop
• Brainstorm success and failure scenarios
– These become your tests
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
7
Structure of a Unit Test
• Arrange
– Set up the System Under Test (SUT)
• Act
– Run the operation(s)
• Assert
– Verify that it worked
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
8
SO, HOW DO I DO TDD IN
VISUAL STUDIO 2010?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
10
Demo
• Using the AdventureWorks database
• Write a test to create a new person
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
13
Why you shouldn’t test: Excuses
• “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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
14
Why you shouldn’t test: Excuses
• “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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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]
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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]
– Method attribute
– Specifies a file that should be copied to the test run bin directory
• [Timeout]
– Method attribute
– Maximum time in milliseconds the test should run
– Use this for Quality Of Service tests
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
19
StringAssert Methods
• Contains(string, substring)
– String contains a substring
– Case-sensitive
• StartsWith() / EndsWith()
• Matches() / DoesNotMatch()
– Uses regular expressions
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
23
THINGS YOU CAN DO WITH YOUR
UNIT TESTS
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
24
Things you can do with your unit tests
• Code Coverage
• Code Profiling
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
26
Code Coverage Demo
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
27
What is the right amount of coverage?
• 100%? 90%? 75%?
• It depends.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
38
Code Profiling Demo
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
39
TESTING NON-PUBLIC METHODS
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
45
Code Demo: Use Protection
• (Ok. You’re all supposed to laugh now.)
• Test a “protected” method
• Create a tester class
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
46
Code Demo: Private Accessor
• Test a private method
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
47
My $0.02
• Favor “protected” over reflection
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
48
SOME BEST PRACTICES
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
59
Data-driven test: Structure
• Structure
– [DataSource()] attribute
– Uses TestContext object
– Accesses the row data via TestContext.DataRow
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
65
Demo: Ordered Test
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
66
PROBLEMS & SOLUTIONS
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
RhinoMocks
• Dynamic Mocking Framework
• By Ayende Rahien
http://ayende.com/projects/rhino-mocks.aspx
• Free under the BSD license
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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()
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo 1: Stub With RhinoMocks
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo 2: Test Exception Handling
• Look at some existing code
• Refactor for testability
• Use RhinoMocks to trigger the exception
handler
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Person Repository
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo 3: Repository Pattern
• Simplify database (or web service) unit test
with a repository
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
DESIGNING FOR UI TESTABILITY
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
How would you test this?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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/
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
UI Testing Tools Are Out There…
• For Windows forms they’re expensive
• For web applications
– Visual Studio Web Tests
– NUnitAsp
• Not 100% awesome.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Web Tests
•
•
•
•
Record paths through your application
Fills in form values
Click buttons
Validates
• Difficult to do test-driven development
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
My $0.02
• Solve the problem by not solving the problem
• Find a way to minimize what you can’t
automate
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
89
Model View Controller (MVC)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
90
Model View Presenter (MVP)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Model View Presenter (MVP)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
• 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
Copyright © 2013, Benjamin Day Consulting, Inc. 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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Model View Presenter (MVP)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Designing the UI for Testability
PersonDetailView.aspx
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
MODEL-VIEW-VIEWMODEL
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
103
Agenda
• My assumptions
• Super-fast overview
– Model-View-ViewModel (MVVM)
– Unit testing
• How to build stuff and test stuff.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Design for testability?
• Way of architecting your application
• Easy to write & run automated tests
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Single Responsibility Principle
•
http://tinyurl.com/ahap3j
• Posters by
Derick Bailey
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
• MessageBoxes
– Alerts and exceptions
• ProgressBar logic
• Model to Data Access
• ViewModel to Model
Overview of unit testing.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
What is a Unit Test?
• Piece of code that verifies that another piece
of code
• Test code verifies application code
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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”
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
So what is this MVVM thing?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Overview of MVVM.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Tip: If you’re writing Silverlight,
figure out your async solution early.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Network traffic in Silverlight
• It has to be async.
• If it isn’t, the UI thread locks…forever.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
My initial client-side architecture.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
My architecture after Async WCF
beat me up and ate my lunch.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Longer discussion of Silverlight async
• http://blog.benday.com/archive/2010/12/24/23300.aspx
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Primitive Obsession in your
ViewModel.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
ViewModelField<T>
• Provides common
functionality for a
property on a
ViewModel
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
With & Without ViewModelField<T>
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo
VIEWMODELFIELD<T>
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo
COMBOBOX & LISTBOX
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo
MESSAGE BOXES
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo
PROGRESS BARS
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Focus your testing on stuff that
tends to be buggy.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Repository & Adapter Patterns
are your friend
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
What is Repository?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Synchronous Repository
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Synchronous SQL Server & WCF
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
A Big Picture
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
What is Adapter?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
My version of Adapter Pattern
• Take object of Type A and convert it in to
object of Type B
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
demo
REPOSITORY & ADAPTER
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
No shortcuts: Keep your ViewModels
& Models separate.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
It’s all about the Cancel button.
• If you’re “two way” data bound,
How do you undo?
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
demo
VIEWMODEL TO MODEL
ADAPTER
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Summary: 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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Other Resources
• http://tinyurl.com/3d2soe8
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Other Resources
• http://tinyurl.com/ln248h
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Other Resources
• http://tinyurl.com/3pf8vxd
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
(Web Performance Testing,
Load Testing, &
Code Profiling content is in
WebLoadTests2010.pptx)
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
169
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
170