http://www.readatwork.com/

A website built to encourage people to read during work. Really clever! It creates a “fake” desktop and you can sit there reading books without anyone suspecting a thing!

I’m working on a personal project atm (more details to come in another post), and needed to use a Point to represent points on a 2D plane, with floating-point accuracy. The Point struct itself works on ints, and i need more precision than that, so i went ahead and created my own AccuratePoint struct.

[HTML1]

Note the use of C# 3.0’s automatically implemented properties. Very neat little feature and saves writing boilerplate code. Try to compile, and it fails with:

Backing field for automatically implemented property must be fully assigned before control is returned to the caller. Consider calling the default constructor from a constructor initializer

Seems odd. It’s telling me that because i’m using the auto-implemented properties, i need to call the default constructor as an initialiser, like this:

[HTML2]

If i fully-implement the properties myself, i don’t need to call the initialiser.

[HTML3]

Which was something i didn’t know about structs – ie: you can’t set values on public properties in the constructor without calling the initialiser first. You can set the value of private fields, but in the case of an autogenerated property, you don’t have access to the private field because it’s created by the compiler….So the moral of the story is that if you’re using autogenerated properties and setting their value in the constructor of a struct, you need to call the initialiser first.

Learnt something new.

EDIT:
I just discovered System.Drawing.PointF….oh well….i’ve now learnt two new things 🙂

This post may be terse and may possibly contain profanity. I’ve just wasted nearly a day and a half before solving this problem.

Situation:
I have Project….Lets call it Project “P”. Big project, .NET 1.1. Nasty stuff at the best of times.
Project A has a dependency on an internal framework project (Dependency “D”).

For the last 2 days, whenever i try and run a unit test using NUnit/TestDriven/ReSharper, my tests are littered with failures like this:

TestCase ‘ProjectP.Test.Data.Documents.MemberAuthentication_Tests.Can_Confirm_Registration’
failed: System.TypeLoadException : Could not load type DependencyD.ISomeInterface from assembly DependencyD.Framework, Version=1.1.0.0, Culture=neutral, PublicKeyToken=8c4881879956f3a5.
at ProjectP.Test.Utility.TestUtility_For_People..ctor()
d:projectsClientProjectClient.websitetrunkProjectP.testingdatapeopleMemberAuthentication_Tests.cs(92,0): at ProjectP.Test.Data.Documents.MemberAuthentication_Tests.Can_Confirm_Registration()

After clearing my local temp and my c:windows temp, i was still getting this error.
After deleting all bin/obj directories in my project, i was still getting this error.
After deleting all known references to “DependencyD.dll” from my system, i was still getting this error.
After lots of googling, nothing turned up which would give me ANY indication that this was a problem.

To solve the problem, I attached the debugger to one of the tests as it ran and looked at the debug output window as it was loading each of the referenced assemblies…here’s what i saw:

C:Documents and Settingsxerxes.battiwallaLocal SettingsApplication Dataassemblydl2GK3YAWO1.PD9R117AEJZ.3263cf8f4b19a0818d9_d632c801DependencyD.dll

wtf? WTF is that directory and why is my dll there? some different Googling and i found the answer. Shadow Copy Cache is a feature of ASP.NET it seems which is the cause of my problems. I wont go into detail about what SCC is, but in a few words, it’s a private copy of all your DLLs for ASP.NET to use so that you don’t get sharing violation problems when your website code is changed.

Deleting the SCC directory and all its contents suddenly make my tests pass, and the world seems brighter once more. I cant FU**ING believe that was the problem. So obscure, i’d never heard of it.

I hope that this entry gets indexed by the search crawlers….i was unlucky in finding anything about this problem by searching for things like “TestDriven TypeLoadException” or “Could not load type from assembly wrong version”, i just dont want the same thing to happen again (or to anyone else).

grrrr….

Recently, i’ve been looking more into TDD and mocking in particular.

I’m well versed with TDD and unit testing in general, and although i’ve dabbled in mocking before with NMock, i never really pursued it deeper; probably based on the combination of a number factors:

• The product i was working on had it’s own in-house, custom-built ORM/OPF which wasn’t interface driven
• There were patterns for testing code based on the aforementioned OPF which didn’t lend themselves for mocking too easily

Either way, i’ve sunk my teeth deep into it, and one thing that irked me about mocking was why I always seem to be mocking interface implementations and not concrete classes. From my (limited) understanding of how mocking frameworks work, one would assume that the definition of an object exposed through public methods on a concrete type would still allow you to mock the object. In a nutshell, i was wondering why can’t i mock my concrete classes?

Lets use an example (apologies if there are compile errors – i’m doing this off the top of my head)….I’m writing a class to perform calculations (uninspiringly named “Calculator”). I realise it’s a trivial example, so lets make it interesting by saying that the actual calculation logic won’t be handled by my application – it will be handled by a 3rd party object called SuperCalculator which takes the calculation and runs it across an array of supercomputers. As developers, we don’t care about the implementation of the SuperCalculator, only its interface.

So my code would look something like this:

[HTML1]

Now to test this using standard mocking techniques, I would need to pray that there is an interface for the SuperCalculator type

[HTML2]

…and the concrete class would be updated to use the interface definition (note the use of setter injection for mocking – i could have just as easily used constructor injection…)

[HTML3]

…and then your unit test starts making a mockery based on the interface (Rhino mocks and .NET 1.1 used here, but using generic params is just as cool)….

[HTML4]

phew…lot of code, but we got there. Now getting back to what irks me. The fact that we had to PRAY for an interface ISuperCalculator ortherwise we couldn’t mock out the dependency. And when you’re at the hands of a 3rd party library, who knows what you’re going to get.

So my questions came to – “is it possible to mock based on the concrete class?”….a bit of light Googling indicates it is possible, but only if you create a superclass of your concrete implementation and override all “public” methods which would now mean that they all have to be virtual by default, otherwise your test will end up calling code with undesirable results.

Why can’t the mocking framework take a concrete implementation, and mock it based on its public interface? The framework knows the interface to the object via reflection (and with VS2008, the intellisense is damn intelligent by allowing you to extend it), so why can’t it Reflection.Emit() all the necessary members (public/protected) and you can avoid the pain of hoping for an interface for a class that’s out of your control?

The other approach to it is to use a service proxy, and proxy all of the calls to SuperComputer through your OWN class MySuperComputer, which requires you to hand code the interface to SuperComputer, expose an IMySuperComputer, and then mock that….You’re hardly achieving anything though, because you’re just pushing the untestable dependency further down.

ramble ramble….if anyone has a thought on the matter, i’d like to hear it. I’m keen on continuing to use mocks, and certainly believe that implementing interfaces is good practice, but when the code you’re trying to mock is out of your control, what do you do?

[UPDATE]
hmm….after looking at this article it seems to explain one reason why you can’t create a pure mock from a concrete class…

Quote:

Dynamic mock object tools like NMock or Rhino Mocks can only override virtual methods. This might not be so much a problem in other languages, but with the .Net languages all methods are non-virtual by default. This means that some of the behavior that you were trying to remove from the test with a mock is still there. The dynamic mock libraries work by using Reflection.Emit to create a dynamic proxy on the fly for the requested interface or abstract class.

bugger

Maybe its the old version of CCNET we’re using, but please be wary of this problem.

After recovering space on the aforementioned drive, you’ll get the following message in the CC dashboard:

Unable to read the specified saved state. The configuration data may be invalid

The solution is to rebuild the content of your .state files for each project affected….And you’ll know which projects are affected because the dang state file is 0 bytes.

Google is your friend.

In Visual Studio 2005 SP1, the new “web-application” project type was introduced. This project type allowed us to have a csproj for the website project and suddenly we were in control of the content of a project and integrating it into an automated build process became simple.

However the best reason for wanting to ditch the old school website project in favour of the web-application project was not needing to bind the project to an IIS website. With an ASP.NET website project, the website project itself needs to be bound to a corresponding website under IIS, which is a real PITA, particularly when you don’t have the necessary environment set up.

So with VS2005 SP1 and web-application projects, all these problems are a thing of the past, right? Wrong, it seems.

I was opening one of our projects written by a contractor and it looks like he’s somehow managed to re-introduce project-website binding in a web-application project. Don’t know how, but whenever the project is opened, if it couldn’t connect to the project’s website running on localhost, it would throw a COM Interop Exception.

Simple solution – remove IIS website binding. It’s unnecessary and provides no benefit if your deployment process is handled outside Visual Studio. Open up the .csproj file, and remove the <ProjectExtensions> element and its children.

Problem solved.