Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Testing In Visual Studio 2010
Benjamin Day
1
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
2
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
How to begin?
• Get an idea for what you want to develop
• Brainstorm success and failure scenarios
– These become your tests
6
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
The Process
• From William Wake’s “Extreme Programming Explored” (Addison-Wesley)
1. Write the test code2. Compile the test code Fails because there’s no
implementation3. Implement just enough to compile4. Run the test Fails5. Implement enough code to make the test pass6. Run the test Pass7. Refactor for clarity and to eliminate duplication8. Repeat
7
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Structure of a Unit Test
• Arrange
– Set up the System Under Test (SUT)
• Act
– Run the operation(s)
• Assert
– Verify that it worked
8
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
SO, HOW DO I DO TDD IN VISUAL STUDIO 2010?
9
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo
• Using the AdventureWorks database
• Write a test to create a new person
11
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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.
14
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
15
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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 re-create 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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
18
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
StringAssert Methods
• Contains(string, substring)
– String contains a substring
– Case-sensitive
• StartsWith() / EndsWith()
• Matches() / DoesNotMatch()
– Uses regular expressions
20
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
THINGS YOU CAN DO WITH YOUR UNIT TESTS
24
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Things you can do with your unit tests
• Code Coverage
• Code Profiling
25
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Code Coverage Demo
27
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
What is the right amount of coverage?
• 100%? 90%? 75%?
• It depends.
28
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Code Profiling Demo
39
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
TESTING NON-PUBLIC METHODS
40
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Code Demo: Use Protection
• (Ok. You’re all supposed to laugh now.)
• Test a “protected” method
• Create a tester class
46
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Code Demo: Private Accessor
• Test a private method
47
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
My $0.02
• Favor “protected” over reflection
48
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
SOME BEST PRACTICES
49
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Data-driven test: Structure
• Structure
– [DataSource()] attribute
– Uses TestContext object
– Accesses the row data via TestContext.DataRow
60
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Demo: Ordered Test
66
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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 vsDummies vs Fakes
• Martin Fowlerhttp://martinfowler.com/articles/mocksArentStubs.html
• Dummy = passed but not used
• Fake = “shortcut” implementation
• Stub = Only pretends to work, returns pre-defined 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 Rahienhttp://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.html
• 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
79
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
From “Patterns Of Enterprise Application Architecture”by Martin Fowler, Randy Stafford, et al.Chapter 9
“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
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
89
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Model View Controller (MVC)
90
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
• 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
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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 Consulting, Inc. www.benday.com 95
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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 TestabilityPersonDetailView.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
103
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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
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 behaviorwithout modifying it.
Liskov Substitution Principle Derived classes must be substitutable for their base classes.
Interface SegregationPrinciple
Make fine grained interfaces that are client specific.
Dependency Inversion Principle
Depend on abstractions, not on concretions.
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
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
• MessageBoxes– Alerts and exceptions
• ProgressBar logic
• Model to Data Access
• ViewModel to Model
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
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-GrainedObject 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 propertiesCoarse 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
VIEWMODELFIELD<T>
Demo
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
COMBOBOX & LISTBOX
Demo
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
MESSAGE BOXES
Demo
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
PROGRESS BARS
Demo
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
REPOSITORY & ADAPTER
demo
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 calledModel-View-ViewModel
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com
Why keep Model and ViewModelseparated?
• 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 populatesitself 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
VIEWMODEL TO MODELADAPTER
demo
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 inWebLoadTests2010.pptx)
169
Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com 170