Thursday, February 23, 2012

A service I need to use for data retrieval recently changed its endpoint definition. The service switched from an HTTP endpoint to an HTTPS endpoint. Since the interface of the service changed as well, I needed to regenerate the interface definitions used to connect to the service.

So, I got out my favourite wsdl tool, svcutil.exe and tried to regenerate the interface definitions as I had done millions of times before. Only to find that the https endpoint was holding me back.

As my command prompt couldn't accept or reject the server's SSL certificate, the wsdl file could not be downloaded.

As a solution for this, you can do the following: Fire up Fiddler and change it's options to decrypt HTTPS traffic. This will add a Fiddler certificate to your certificate store, which is just fine by me.

I did not check the 'Ignore server certificate errors' option, since I still want to know what's going on when some process is going to an HTTPS site.

After setting these options and while Fiddler was silently running in the background, I tried out the svcutil command again. This gave me one more pop up (since I did not check the certificate errors option).

Wednesday, February 22, 2012

On one of my last projects, I started using Fitnesse tests, primarily to give the business the opportunity to specify their test cases. After playing around with these tests for about 4 days, I, however, threw them out. The main reason for this was the fact that I had to write a whole lot of complementary code to get the Fitnesse tests to run properly.

With Fitnesse, you first need to specify input and output data for your test case. This means edditing a web page with data and writing fixtures in code to process this data. This takes some getting used to and, in my opinion, requires quite some coding. I am also used to refactoring (and renaming) quite a bit during development. But sadly, your Fitnesse test cases don't get refactored, since they live in a separate web application. I also gave myself some extra work by switching over from the slim test runner to the fit test runner. Apparently if you do this, your previously written test fixtures aren't compatible anymore. Something I found very disturbing.

After 4 days of writing Fitnesse tests, I had about 3 test cases finished, I had only a small bit of business code and a huge headache. So, I threw them out.

Instead, I started using MSpec, or Machine Specifications. It is used to write business driven tests, or employ BDD in your code. Now, although MSpec is good for doing BDD, I have noticed it's not because you are using MSpec, that you are doing BDD. You can still write tests the way you used to with NUnit for instance. MSpec is actually just a semantic layer on top of that. But still, it makes it easier to move towards a BDD kinda style of programming.

I must say I really like the way in which you write you MSpec tests, although it does have some downsides and some bits take getting used to as well. I don't think the MSpec tests are always as readable as you would wish. On the one hand, it's nice they make use of lambda expressions a lot, on the other hand, the indentation on those lambdas is just plain awful. It does make you follow an AAA style of testing. Although with MSpec they don't call is Arrange, Act, Assert, but Establish, Because and It. That's just different naming, in essence it's the same thing, right. Another downside is, you can't give these tests to your business users to write them up. It's still developer testing.

This had me looking at SpecFlow, another framework I tried out a couple of weeks later. The test cases you write are more in a business kind of style. They are also easier to write by a business representative (with some additional explanation that is). Once you read the SpecFow documentation you would think you can only test web apps with it in combination with Selenium, but actually, I found it's dead easy to test plain business code with it as well. As with Fitnesse, your SpecFlow tests require you to write some additional code to link your test cases with the actual code, but the good thing is, SpecFlow helps you a lot with this. I used it in combination with my good friend ReSharper and found that this goes very smoothly. If I haven't written any code for a SpecFlow test case, ReSharper suggests a dummy implementation for it which you can copy paste and alter as much as you'd like. That's neat. Only downside I see for now is it's inability to use it for real technical tests. It's not technically impossible, but that's not what it was designed for. Your SpecFlow tests should always be backed up by technical NUnit test cases. That's why it's recommended that you read the Cucumber backgrounder on how to write test cases. The do's and dont's are pretty important here.

I'm actually still playing around with SpecFlow for now. MSpec has already proven it's worth, as did plain NUnit tests. But I think it would actually help a lot to write even more SpecFlow test cases in close communication with the business. I think this is a framework that can deliver.

Tuesday, February 7, 2012

I am currently using PostSharp to add logging and exception handling aspects (to name a few) to an application. PostSharp does this very well and my code has become quite a bit more readable thanks to it. PostSharp actually weaves in extra functionality during your build process. And it can be easily added to an existing project using a nuget package installer.

A recent change in the application however had me refactor out some of the classes I'd added aspects to, to another assembly in the same application. After the refactoring I also added the PostSharp dll to the new project and realized my aspects weren't added/weaved in during the build. This had me thinking, since I did add the PostSharp dll to the new project. After some searching, I found the source of the problem.

Since PostSharp adds extra functionality during your build, you'll need to tell your project (or the C# compile process, that is) to execute this extra PostSharp funcationality. The nuget package actually added this to my original project, but not to any other project in the same solution. So, to solve this, either rerun the nuget package installer on the other project, or, just as easy, add the following xml tag to your csproj file (somewhere at the bottom).

You get this explanation as well in your projects' properties. You will notice an extra PostSharp tab there, that is either enabled - if PostSharp is doing its' thing - or disabled - if it is not, which was the case for me.