Design Patterns for MVVM Unit Testing & Testability

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