design patterns for mvvm unit testing testability n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Design Patterns for MVVM Unit Testing & Testability PowerPoint Presentation
Download Presentation
Design Patterns for MVVM Unit Testing & Testability

Loading in 2 Seconds...

play fullscreen
1 / 62
vartan

Design Patterns for MVVM Unit Testing & Testability - PowerPoint PPT Presentation

86 Views
Download Presentation
Design Patterns for MVVM Unit Testing & Testability
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Design Patterns for MVVM Unit Testing & Testability Benjamin Day

  2. Benjamin Day • Consultant, Coach, Trainer • Scrum.org Classes • Professional Scrum Developer (PSD) • Professional Scrum Foundations (PSF) • TechEd, VSLive, DevTeach, O’Reilly OSCON • Visual Studio Magazine, Redmond Developer News • Microsoft MVP for Visual Studio ALM • Team Foundation Server, TDD, Testing Best Practices,Silverlight, Windows Azure • http://blog.benday.com • benday@benday.com

  3. Agenda • My assumptions • Super-fast overview • Model-View-ViewModel (MVVM) • Unit testing • How to build stuff and test stuff.

  4. 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.)

  5. Design for testability? • Way of architecting your application • Easy to write & run automated tests

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

  7. SOLID Principles of Class Design http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

  8. Single Responsibility Principle • http://tinyurl.com/ahap3j • Posters by DerickBailey

  9. Things that need to be tested. Goal: test your application without running the UI MessageBoxes Alerts and exceptions ProgressBarlogic Model to Data Access ViewModel to Model • ComboBox / ListBox • Population of lists • Selection logic • Field-based logic • Value, Visibility, Validation • Dependencies between fields

  10. Overview of unit testing.

  11. What is a Unit Test? • Piece of code that verifies that another piece of code • Test code verifies application code

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

  13. 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”

  14. So what is this MVVM thing?

  15. Overview of MVVM.

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

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

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

  19. Tip: If you’re writing Silverlight,figure out your async solution early.

  20. Network traffic in Silverlight • It has to be async. • If it isn’t, the UI thread locks…forever.

  21. My initial client-side architecture.

  22. My architecture after Async WCF beat me up and ate my lunch.

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

  24. Longer discussion of Silverlight async • http://blog.benday.com/archive/2010/12/24/23300.aspx

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

  26. Primitive Obsession in your ViewModel.

  27. 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?

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

  29. ViewModelField<T> • Provides common functionality for a property on a ViewModel

  30. With & Without ViewModelField<T>

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

  32. Demo ViewModelField<T>

  33. Demo ComboBox & ListBOX

  34. Demo MESSAGE BOXES

  35. Demo Progress Bars

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

  37. Focus your testing on stuff that tends to be buggy.

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

  39. Repository & Adapter Patterns are your friend

  40. What is Repository?

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

  42. Synchronous Repository

  43. Synchronous SQL Server & WCF

  44. A Big Picture

  45. What is Adapter?

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

  47. My version of Adapter Pattern • Take object of Type A and convert it in to object of Type B

  48. 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.)

  49. 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)

  50. demo Repository & ADAPTER