Unit tests more complicated than the code?

•March 11, 2010 • Leave a Comment

I spent some time this morning coming up with a nice way for us to test our Linq expression trees against lists when using NHibernate. Who knows, perhaps when I’m a bit less lazy I’ll actually post it here…

I thought it was quite an elegant solution and proceeded to show my colleague, who is currently doing a lot of pair programming with me.

My colleague is a bit new to unit testing, mocking and such and immediately exclaimed that it’s more complicated than the code itself! Well, usually I don’t take it as a compliment if somebody calls something I came up with “complicated”, but in this case I did. The “complicated” code is a once off effort, which makes it easier to do unit tests for our repositories in the future. 

I think it summarises why I like doing TDD, because you can get your hands dirty with some real comiplicated problems which you need to solve. What developer doesn’t like a challenge?

Perhaps my colleague’s reaction explains why a lot of developers don’t fully embrace TDD, because it’s sometime a bit hard and you really need to know your way around the CLR to find a solution.

Pair programming

•February 13, 2010 • Leave a Comment

I’ve been pair programming on and off for a few years. I enjoy pair programming. At the start, and I’m sure that almost every developer feels this way initially, I was quite suspicious and lets face it a bit scared. I soon realised though, that my fears were all for nothing and started enjoying it immensely. When pair programming I don’t have to defend my code to anybody, there is no real need for code reviews and I don’t get stuck with supporting a module till the day I die, because nobody else understands it.

I’m always amused when management (also project managers) ask the question: “But won’t it take twice as long to go through all your work if you pair program the whole time?”. I guess when you’ve seen it working countless times it’s kind of a shock to realise that some people are still sceptics. I can understand it though, I also posed the same question when I first heard of it.

In my experience it does not take twice as long, but approximately the same time to do the same work. By that I mean that in my experience two pair programmers will go through 20 story points in about the same time as 2 non pair programmers working on their own machines. Reason being, there is no time to read all your email when it comes in, or chat with your wife on google talk, read up on latest technologies, generally just wasting valuable time – that would just be rude! It’s also more difficult to go off on a tangent, becasue your code partner will prevent that. What’s more the quality of the code is better, knowledge sharing happens continiously, less bells and whistles come into existence and it’s exciting!

I guess it’s not always possible to convince people that it works, but it sure as hell is worth trying.

WF4 Workflow loaded from xaml with references to custom activities

•January 8, 2010 • 1 Comment

I wanted to test loading  a WF4 workflow directly from it’s Xaml while it references custom activities.

I wasted quite a lot of time, because my custom activity was in the same project as both my workflow and the code that invokes it, and it seems that doing this does not work.

So if you need to do this, ensure that you put the activity that you reference from the workflow in a separate activity library project.

You can find more information on the thread which I logged at Microsoft:

http://social.msdn.microsoft.com/Forums/en/wfprerelease/thread/bfbc0c01-7205-4fb4-8b3a-260c9d6db37f

UITypeEditor scenario in WF4

•January 7, 2010 • Leave a Comment

When you author custom activities in WF3, you usually need to develop UITypeEditors in order to allow you to show a custom dialog when someone wants to provide a value the activity in the property grid. For example, to allow the person to browse to a file, or something a bit more advanced, like selecting an entity from your system.

This is surprisingly easy to do, even if you have just a rudimentary understanding of winforms.

I found it a bit challenging to start doing stuff like this in WF4, because just as you need to understand winforms a bit in order to author custom activities in WF3, you need to understand WPF to do the same in WF4.

I’ve never really worked with WPF, except for hacking a Silverlight uploader to do exactly what I want…

But luckily WF4 has forced me to look into this interesting technology.

Anyhoo, back to the issue at hand. In order to do the same in WF4 as you would achieve with UITypeEditors in WF3, just download the samples from: http://www.microsoft.com/downloads/details.aspx?FamilyID=35ec8682-d5fd-4bc3-a51a-d8ad115a8792&displaylang=en and have a look at the following sample: \WF_WCF_Samples\WF\Basic\Designer\PropertyGridExtensibility.

This is also a nice walkthrough on how to do this in WPF: http://msdn.microsoft.com/en-us/library/bb546930.aspx.

Rhino Mocks: Anonymous method for Do Handler

•November 26, 2009 • Leave a Comment

I haven’t been doing a lot of unit tests lately – gasp! I’ve been doing a LOT of Javascript sorta stuff in the last year, which has been interesting for a change, but I’m really happy it’s over now.

I’m back to doing proper development, and I forgot how to use an anonymous method for a Do() handler!

Luckily I quickly stumbled on to this post by Igor Brejc: http://igorbrejc.net/development/c/rhinomocks-do-handler-using-anonymous-delegates.

I wanted to do something when a wrapper I developed for the WorkflowRuntime class adds the ExternalDataExchange service to the runtime, so I ended up with something like this in my test:

                Expect.Call(() => mockWorkflowRuntime.AddService(null))
                    .IgnoreArguments()
                    .Constraints(Is.TypeOf(typeof (ExternalDataExchangeService)))
                    .Do((Action<ExternalDataExchangeService>)delegate(ExternalDataExchangeService service)
                                     {
                                         //do my stuff here
                                     });

Custom editors for Windows workflow activity properties

•November 26, 2009 • Leave a Comment

I’m working on a real nifty project where I’m developing a workflow server for automation purposes. We’re using WF3 for it, and I must admit I’m enjoying it a lot. I haven’t worked with it since start the start of 2007, so it’s nice getting back to it.

I’ve forgotten a lot of the nitty gritty stuff, so I get to learn some stuff over again 🙂

When developing custom activities for WF, you obviously want to allow the person who’s going to use the activities in the end to easily provide values for any properties that the activity might have. For example, if your activity needs a path to a directory, you can leave it as a string and expect the person to type in the path, but this is prone to error. It’s much better to provide the user with a dialog to select a folder, isn’t it? In comes UITypeEditor…

I remembered that I’ve done it several times, but hey 2.5 years is a looong time in which to forget stuff like this.. Luckily I found a real nice example on how to do this in this post by Tomas Restrepo: http://winterdom.com/2006/08/acustomuitypeeditorforactivityproperties/comment-page-1.

UITypeEditor

Bulk Yui compressor script

•June 5, 2009 • Leave a Comment

We’ve been using JSMin for our JavaScript minification purposes.

As I’m currently tasked to improve our website’s initial loading performance by more than 50%, I started looking at also minifiying CSS files.

I read up on Yui Compressor, because it allows you to minify CSS. I read that it also results in smaller JS minified files than other minification strategies, and gave it a go on our JS files. I wasn’t disappointed, it gave us 10% reduction in size than with JSMin.  

Seeing that we’ve got a hell of a lot of JS libraries in our site, I came up with a strategy to bulk minify all our JS files in one go as part of our build process.

I’ve been burning to do some PowerShellscripting again, so I developed a script which minifies all our JS and CSS files. You’ll have to be familiar with PowerShell, and if you aren’t why not?! You’ll also have to change the paths to match your environment.

$yuiPath = “..\lib\Repository\YahooUI\yuicompressor-2.4.2\build\yuicompressor-2.4.2.jar”

$scriptFiles = Get-ChildItem “..\OlrWebApp2\scripts” -r
foreach($file in $scriptFiles)
{
    Write-Host(“MINIMIZING ” + $file.fullname)
    $targetFile = $file.fullname -replace(“.js”, “_min.js”);
    java -jar $yuiPath $file.fullname -o $targetFile
}

$stylesheets = Get-ChildItem “..\OlrWebApp2\Branding\cpu” -r -include *.css
foreach($file in $stylesheets)
{
    Write-Host(“MINIMIZING ” + $file.fullname)
    $targetFile = $file.fullname -replace(“.css”, “_min.css”);
    java -jar $yuiPath $file.fullname -o $targetFile
}

Write-Host(“Done”)
$null = $host.UI.RawUI.ReadKey(“NoEcho,IncludeKeyDown”)