ailon's DevBlog: Development related stuff in my life

Unit Testing Combo WPF/Silverlight Projects

9/23/2010 8:24:52 PM

With release of WPF 4 and Silverlight 4 creating WPF and Silverlight applications sharing the same code became easier and less frustrating than it was before. The main techniques that I described in my series for WPF 3.5/Silverlight 3 (“Add as Link”, partial classes and preprocessor directives) are still the most reasonable approach for this task.

It is also commonly agreed that your ride will be smoother if you start with Silverlight. This doesn’t mean that you have to leave WPF for later. What this means is that you create files in your Silverlight project and “Add as Link” to your WPF project (not the other way around). The main benefit of this approach is that you get Intellisense , etc. for Silverlight and, since Silverlight doesn’t have all the classes, methods and overloads that full .NET framework has, you won’t be tempted to use them.

A very simple solution utilizing this approach would look something like this:

image

So What About Unit Testing?

If you are some unit testing fanatic you might want to unit test WPF part with MSTest (or other testing framework) and separately unit test Silverlight part with Silverlight Unit Test Framework. Now this would be good in test reliability but I can bet you won’t run both of them anyway and since most of your code is identical you would probably want to unit test that common code with only one of the testing suites.

It wouldn’t come as a surprise if you decide to use MSTest running inside Visual Studio over SilverlightUT running in browser. The problem here is that you are doing Silverlight project first and you can’t add a reference to your Silverlight project to the MSTest project.

image

So what you have to do if you want to go this route is constantly add new files to your WPF project and reference that project from the test project.

image

Problems with this Approach

Unfortunately this approach is far from perfect.

First of all it’s problematic to do TDD/tests first. When you write a call to a not yet defined method and try to generate method stub using Visual Studio you get this error:

image

This happens because you have MyControl.cs file open from a Silverlight project and the tool tries to generate the stub into WPF project and fails because the file is already open from another project. Now if you close the file as the message box suggests, the generation will succeed but it will open the file from the WPF project and you won’t be doing Silverlight-first unless you close the file again and reopen it from the Silverlight project again.

Then there’s a similar problem with refactoring/renaming. When you have your file open from the Silverlight project and you rename a method, class, property, etc. using Visual Studio refactoring tool it won’t be renamed in the test project. So you’ll have to go and do a bunch of manual finding and replacing.

These are obviously not critical issues but pretty annoying nevertheless. It’s very important that writing tests is as painless as it could be or you won’t write them. And pain is pretty much a part of the process considering these issues.

Hopefully there’s a better way to unit test such projects and I’m just not aware of it. If so, please, let me know in the comments.

Shout it kick it on DotNetKicks.com

Tags: , , ,

Book Review: The Art of Unit Testing by Roy Osherove

2/2/2010 7:49:36 PM

The Art of Unit Testing by Roy Osherove

Personal preface

I must admit – I haven’t been doing any real-life unit testing until now. Back in 2004 I was leading a relatively big WinForms project and I thought we should do unit testing on it. Unfortunately we had already finalized our conceptual designs (which didn’t consider unit testing), the tooling at the time wasn’t as mature as it is now and, most importantly, we had no knowledge on how this unit testing thing should be done properly. So after playing around with NUnit for some time I’ve concluded that it was neither the time nor the place to start doing it for real and put it away.

After that project I was mostly involved with smaller ASP.NET projects and never thought that unit testing was really feasible for them. So, basically unit testing was always somewhere on my mind but not too close to the surface.

Five years later I’ve started working on amCharts for WPF & Silverlight and as we release new products, add new features and fix bugs I’ve started feeling a real fear of breaking something while fixing a bug or adding a new feature. Manual testing helps but the fear is always there. I understood that it’s time for “take 2” on unit testing.

This time I knew that I have to do it right. This is one of those subjects where you can’t just start doing it and learn as you go. That is a sure way to fail (see my experience above).

The Book

Fortunately this time there is this book and it’s targeted at .NET developers which is not essential but a nice bonus. I’ve been reading Roy Osherove’s blog for quite some time and following him on twitter. I’ve been using his Regulator regular expression testing tool before that. So, I sort of “knew” and respected the author, the book got raving reviews at Amazon – buying it was a no-brainer.

The book is short (less than 300 pages) but on point with almost none “water spilled” and space wasted. I’ve swallowed it in less than a week reading it in the evenings only. That wouldn’t be that fast for a fiction book, but I think that’s a record for me for a technical book. I usually fall asleep reading technical books in bed pretty quickly and I only did it once with this book ;)

It covers all the aspects of unit testing, writing good tests and testable code, tooling for .NET (also mentions tools for Java, C++, etc.). It also offers quite strong author’s opinions on the matters. Some people might not like this, but as long as you can see that it’s an opinion and not something written in stone, I really do like it.

Minor Criticism

I can’t say anything bad about the content of this book, but I have a few minor complaints about presentation. First of all I didn’t like the font used. I’m no expert of fonts and this could be the default Manning (publisher) font, but it didn’t feel right to me (too wide or something). The use of some “comic” type of font for ToC and headings is another story, but since it’s not the main font it didn’t bother me much. There were some minor issues with sample code too: incorrect indentation, a couple of auto-capitalized “return” statements and things like that, but nothing major.

The book comes with free access to ebook version in PDF, ePub and Mobipocket formats w/o DRM (as far as I understand). Unpleasant thing was that my name and email address was inserted in the footer of every page of the PDF. I don’t even know what is more unpleasant DRM or this. Should I protect the PDF now so it doesn’t spread over internet accidentally or something? If I wanted to spread illegal copies I’d find a way to remove this, but now I don’t even feel comfortable giving that PDF to my colleague which I consider a fair use (I’ll give him a paper book anyway). Anyway this is a minor issue and I should stop complaining.

Conclusion

If you are serious about starting unit testing or improving your skills, do yourself a favor and don’t just jump right in, but buy this book (especially if your main platform is .NET). It’s a really excellent starting point for anyone who doesn’t consider himself a unit testing guru (and I guess even gurus might find something new). After reading this book I feel pretty confident that my next project will include unit tests and I’ll have a good basis and this book as a reference if I have questions.

Links

Tags: , ,

Copyright © 2003 - 2017 Alan Mendelevich
Powered by BlogEngine.NET 2.5.0.6