Visual Studio Unittest Inheritance

As your project thus your unittests grow and get more complex you might have to use every Object Oriented "trick" in the book to keep your UnitTests lean/mean/fast and flexible. Of course you don't want any redundant (unittest)code so applying inheritance to your unittests might seem a natural step (especially with provider/Inversion Of Control/Plugins beging used more and more).

Inheritance of UnitTests for Visual Studio however, still, is only partly supported by Visual Studio 2005 and Visual Studio 2008 (all editions). You can't define your baseclass/derivedclass in seperate assemblies.

To me this is a big limitation and the "obvious" solutions offered by Microsoft (copy/paste or add twice) for me are no option. I rather go for sharing in my version control system.

Just an other example of why UnitTesting as offered by Visual Studio so far "feels" a bit unmature. Speaking of which: the atrributename of "fixture" is so much more right then "testmethod"...

======== From MSDN =============

A test class is any class that is marked with the TestClass attribute. Test classes can now inherit members from other test classes. This means that you can create reusable tests in base test classes; derived test classes can inherit tests from base test classes. This feature eliminates duplicated test code and gives developers more flexibility while unit-testing production code.
A test class cannot inherit from a class that is in a different assembly. You can circumvent this limitation in the following way:

• Define your base test class in a source code file and add the file to Project A.
• Add the same source code file to a different project, Project B. To do this, right-click the project in Solution Explorer, click Add, click Existing Item, and then use the Add Existing Item dialog box to select the file.
  Although Project B builds into a different assembly, it includes the base test class. Other test classes in Project B can inherit from that base test class

===============================


For more information:

Visual Studio 2005: http://support.microsoft.com/kb/919649
Visual Studio 2008: http://msdn.microsoft.com/en-us/library/ms182516.aspx

Happy Testing!

Bad Architects (Quote)

"We would not discuss so abstract about Architecture if we were not such bad Architects."

Marcel van Eijkel, 30 oktober 2008 (based on a quote of Friedrich Nietzsche)

ASP.Net Ajax Update Panel Quirks

Mainly as a reference for myself, when working with the ASP.Net UpdatePanel remember the following limitations, I have encountered sofar:

• Radiobutton-triggers only work if you set no default value (you can set it from the codebhind) see: http://forums.asp.net/t/1126914.aspx
• Script-blocks don't work if you want it anyway there is a nice solution here: http://weblogs.asp.net/infinitiesloop/archive/2007/09/17/inline-script-inside-an-asp-net-ajax-updatepanel.aspx

For now, I am a big fan of the updatepanel because it gives me the user experience benefits of Ajax without the (architectural) impact.

Microsoft's Ajax Strategy

With only a bugrich codeplex AJAX Toolkit available, professional ASP.Net Developers were forced to count their options outside the Microsoft playfield. Fast amounts of time were and are invested in encorperating Ajax-frameworks into ASP.net. Just think of Backbase, Dojo, Prototype and Yahoo to name a few.

But there is hope If you are a fan of Scott Guthrie it can't be a suprise, Microsoft future direction for their Ajax strategy will be "JQuery". Atleast that is what I expect given the influence that Scott has and the recent beta release of the mvc-framework heavily depending on JQuery.

My experiences with JQuery are amazin: in the very first place it is very very practical. Its amazing what one can accomplish with a few, intuitive, lines of code.

Secondly, the availability of ready-to-use components build on "JQuery" is rapidly increasing.

So my advise: start experimenting with "JQuery" today, and learn the basics.

See: http://www.jquery.com/

Quote about recognizing a leader

Iedereen met een doel, die van anderen afhankelijk is om dat te bereiken, is een leider.

21 oktober 2008, Marcel van Eijkel

=====

(translation)
Anyone, who has a goal being dependent on others to accomplish it, is a leader.

Null Column Values in Linq2SQL ( isNull, Linq )

Just wanted to share that a common mistake using Linq2SQL is to use the "equals operator" if you want to find a row that has null-values in certain columns.

Wrong:
From table in context.Table where (searchValue == table.Column)
Results in "from Table where Column=null"

Right:
From table in context.Table where (Object.Equals(searchValue, table.Column))
Results in "from Table where Column is null";

Happy Linqing!

PS: the reason I am using Linq2Sql and not Linq2Entities because of the current lack of disconnected entities support. I tried it but it was way too time consuming to use the conceptual layer as a business/object layer.

Decorator Pattern using the Unity Framework

Realizing the decorator pattern in the DotNet-Framework has always been easy.

But, with the arrival of the new Unity (Inversion Of Control) Framework setting this up is less intuitive.

Below a config-based example (mainly for my own reference) copied from a codeplex discussion see:

http://www.codeplex.com/unity/Thread/View.aspx?ThreadId=24015


Happy decorating!

WCF Windows Service (Debugging)

Seeing the popularity of SOA rising, Microsoft's WCF services are rightfully being used more and more. Ofcourse, those services need to be hosted somewhere. One of the options for this is in a Windows Service (or technically speaking in a Process Service).

But, with the development of Windows Services comes the, generally accepted, burdon of deploying (compiling, installing, starting, attaching debugger, stopping, uninstalling) these services with every change we make, atleast if we do this by the book.

Not settling for that situation I counted my (too many) options and choose the following stratagy:

1) As goes without saying, allways make sure your service has hardly any "guts". Have all the logic in a seperate class that is seperately and indepentdently unittested.

2) Add a "program.cs" to your WindowsService-project, change its type to "Console Application" finally have Visual Studio start that project up when you start debugging your solution. (see source here: Run-windows-service-as-a-console-program.

Happy Servicing


Notes:

• Don't worry, by changing the type to "Console Application" you only tell Visual Studio to start (technically speaking "exec"-buildtask) the main-function of the program.cs you can still deploy your services without any changes to the sources/binaries.
  
  
• Try to group your Services in one Windows Services (technically speaking adding multiple appdomains to the process). If applicable this does save a significant amount of memory.
  
  
• Microsoft's upcoming OSLO concept might make this approach less needed;
  
  
• Add the following configuration block to your "app.config" to get usefull Console output:

<system.diagnostics>
  <trace autoflush="false" indentsize="4">
   <listeners>
    <add name="configConsoleListener"
type="System.Diagnostics.ConsoleTraceListener">
   </listeners>
  </trace>
</system.diagnostics>

Quote about being reasonable

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.