views:

135

answers:

1

Hi I've searched some other posts, but most of them assumed that people knew what they were doing in their unit testing, and frankly I don't. I see the idea behind unit testing, and I'm coding an silverlight application much in the blind right now, and I'd like to write some unit tests to kind of be sure I'm on the right path. I'd like to be able to use the SL4 vs 2010 silverlight unit test project template, to keep it simple and not use external tools. So what I need an answer for are questions like:

what are the methods of unit testing? what are the differences between unit tests, and automated unit tests? How do I meaningfully unit test in silverlight? What should I be aware of while unit testing (in silverlight) ?

Also should I implement some kind of IRepository pattern in my silverlight app to make unit testing easier?

EDIT:

I will be posting useful links here as I explore this along the way:

Implementing MVVM in silverlight - http://community.infragistics.com/pixel8/media/p/91949.aspx

Mix10 MVVM talk - http://live.visitmix.com/MIX10/Sessions/EX14

Unit testing Ria apps - http://blogs.msdn.com/b/vijayu/archive/2009/06/08/unit-testing-business-logic-in-net-ria-services.aspx

PK's great resource: http://dotenetscribbles.blogspot.com/2009/12/unit-testing-dependency-injection-and.html

+2  A: 

I have never used silverlight unit test project template. I have only used nunit to do unit testing in silverlight. So, I will leave that for someone else to answer. As far as your other questions are concerned:

Unit testing should drive your design. Your unit tests are first users of your code. Your code is based on some expectation and unit tests verify that expectations are being met. Using MVVM pattern (as you are using silverlight), facilitates unit testing. The most important thing to remember is that you have to write testable code. And to write testable code, the most important thing to remember is to inject dependencies. For example, if your code makes a call to the db. You, can't have a unit test making a call to the DB. Instead, you will mock your data acccess layer. This is where concepts like mocks and stubs come into picture. I use moq for mocking in my sivlerlight unit tests. Another, important thing I follow which I think facilitates unit testing is single responsibility principle. Finally, treat your test code as production code, else your tests might give you a false notion, that expectations are being met. Your unit tests are code and hence can have bugs.

what are the differences between unit tests, and automated unit tests?

I am not very sure what do you mean by this. Unit tests are an automated way of white box testing. You can have scripts which run all unit tests, every time you checkin any code in the repository. This can be part of continuous integration.

How do I meaningfully unit test in silverlight

In silverlight, to facilitate testing you should use commands, instead of writing code in code-behind files. This allows you to simulate button click and other GUI events while unit testing. Using MVVM pattern along with commands, you can test all of C# code (not xaml), right up to UI (Converter, VMs, etc).

It is very difficult to mention everything in this one answer. I would suggest, you google for MVVM, commands in Silverlight, Martin fowler - mock are not stubs, mocking frameworks for silverlight, dependency injection

P.K
I'm hoping that you could implement something without drastic changes to the app. i.e I see this: public IQueryable<aspnet_User> GetAspnet_Users() { return this.DataContext.aspnet_Users; }and I notice that the return is this.DataContext.aspnet_Users, so Isn't there a way to just switch out the datacontext with some kind of mock-db and then run the domainservice methods in my test class?I mean, to my untrained eye, I would have something like this.DataContext = MockDBStructure;MockDBStructure : IDBStructureisn't that possible?
Jakob
@Jakob. it is very much possible to mock IDBStructure implementation. So, I am assuming that your are receiving DataContext as a dependency or the class instance which has the method GetAspnet_Users() (implements some interface) is injected (passed thru ctor/property/method).
P.K
@PK. Currently The DomainService containing the GetAspnet_Users() method is definded as public class DomainService : LinqToSqlDomainService<HRDataClassesDataContext>so I'm not really sure how I would exchange the datacontext, to get some IRepository pattern implementation to facilitate unit testing
Jakob
The DomainService class should implement some interface, say IDomainService which will serve as a contract for its clients. It will have GetMethods like GetAspnet_Users(). Classes in your other layers will have a ctor param, something like this OtherLayer(IDomainService){...}. When you test classes in other layer, you will have to mock IDomainService and pass that object to class under test
P.K
@PK - thank you for your persistence in answering my questions :) I must be not getting something here. If I have to mock the domainservice I will have to write methods in the mockdomainservice that are only analogous and not identical to the ones in the actual domainservice, which gets me thinking - what Am i testing then other than the output of my mockdomainservice. From my perspective testing against my local DB actually looks more attractive than using that solution, because then I'd atleast be testing real data, and the real domainservice methods. Can you deduce what I'm not getting?
Jakob
First and foremost you have to decide what do you want to test? You want to test layers which consume data are doing it as per your expectations. Hence, in your unit tests you don't want to hit the DB. Instead you want to create methods which will return you dummy objects and then see how your layer consumes those objects. Testing against DB are not unit tests. Your DB is bound to change and this will fail your tests. You want your unit tests to be repeatable.
P.K
@Jakob-I would suggest you read some text on unit testing. Roy Osherove's The Art of Unit Testing is a very good book. Also, Pramatic Unit testing is another good book to read. Also, you can go thru this presentation I had given - http://dotenetscribbles.blogspot.com/2009/12/unit-testing-dependency-injection-and.html
P.K