Visual Studio 2010 Unit Testing

Copyright © 2013, Benjamin Day Consulting, Inc. www.benday.com

Testing In Visual Studio 2010

Benjamin Day

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]

2

http://blog.benday.com/

mailto:[email protected]


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 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


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 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


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]– 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


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 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

http://martinfowler.com/articles/mocksArentStubs.html


RhinoMocks

• Dynamic Mocking Framework

• By Ayende Rahienhttp://ayende.com/projects/rhino-mocks.aspx

• Free under the BSD license

http://ayende.com/projects/rhino-mocks.aspx


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.html

• Encapsulates the logic of getting things saved and retrieved

http://martinfowler.com/eaaCatalog/repository.html


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

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


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 Consulting, Inc. www.benday.com 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


Model View Presenter (MVP)


Designing the UI for TestabilityPersonDetailView.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

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

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod


Single Responsibility Principle

• http://tinyurl.com/ahap3j

• Posters by Derick Bailey

http://tinyurl.com/ahap3j

http://creativecommons.org/licenses/by-sa/3.0/us/


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




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




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-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


ViewModelField<T>

• Provides common functionality for a property on a ViewModel


With & Without ViewModelField<T>


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


VIEWMODELFIELD<T>

Demo


COMBOBOX & LISTBOX

Demo


MESSAGE BOXES

Demo


PROGRESS BARS

Demo






• MessageBoxes

• ProgressBars




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

http://martinfowler.com/eaaCatalog/repository.html


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)


REPOSITORY & ADAPTER

demo






• MessageBoxes

• ProgressBars




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 calledModel-View-ViewModel


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.


It’s all about the Cancel button.

• If you’re “two way” data bound, How do you undo?


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.


VIEWMODEL TO MODELADAPTER

demo


Summary: Our “To Do” list




• MessageBoxes

• ProgressBars




Other Resources

• http://tinyurl.com/3d2soe8

http://blog.benday.com/images/blog_benday_com/Windows-Live-Writer/7014aa3d3d79_B79A/SNAGHTMLba17d85.png


Other Resources

• http://tinyurl.com/ln248h

http://tinyurl.com/ln248h

http://blog.benday.com/images/blog_benday_com/WindowsLiveWriter/ArticleEliminateDatabaseDependenciesinTe_7895/image_2.png


Other Resources

• http://tinyurl.com/3pf8vxd

http://tinyurl.com/3pf8vxd


(Web Performance Testing,Load Testing, &

Code Profiling content is inWebLoadTests2010.pptx)

169

Visual Studio 2010 Unit Testing

Documents

Transcript of Visual Studio 2010 Unit Testing