Dennis van der Stelt

TypeMock Isolator and LINQ

I’m doing some work with TypeMock and I start to love it more and more. For example, how about removing your database completely from your continuous tests? Sure you can do some database testing during the nightly build, but please keep the tests as fast as possible.

A little story about a build
Just a few days ago on a Friday my colleague Alex Thissen and I were planning to leave the building. Unfortunately after checking in some code, a few unit tests failed in Alex’s project. It were some really minor changes, but as it was 20:00 hours already, we weren’t as sharp anymore. After 4 trial-and-error sessions getting the test to work, we could go home. The code changes took only a few seconds, running the build took much, much longer. Mainly because Visual Studio 2008 for DB Professionals was deploying the database every time. What if we only needed that during the nightly build and actually had the continuous build running much faster?

Imagine a nice little table like the one on the right. Just some Class-A trainers in there. Imagine some code retrieving the trainers.

Normal ADO.NET code for retrieving trainers and adding them to a collection of MyTrainer objects. We could just test this with a special test database so that we always get the same results. We could create a very easy test where we just execute the GetTrainers method and see what data it returns. But as this accesses the database you might want to do this in a nightly batch. To be a little more sure you don’t break the build at night, you can always run these tests from your local machine.

But we really want to test the code without actually connecting to the database. You could stub out a lot, but that’s a lot of work. Especially because the datareader is very hard to stub out. I’ve once used a datareader that was running on a dataset with one ore more tables in it. Pretty nice, but still took a whole lot of code to fill the datareader initially.

When we want to use a mocking framework like TypeMock, it still requires some code. We need to actually mock out three objects and create expectations for them. Here’s the code.

As you can see we set up a recorder and created expectations for the values that should be returned. The reader.Read method should return true twice so we can fill two MyTrainer objects with data. We then set expectations for the two times the name column is accessed using the reader. When finished recording, we actually execute the code we’re testing and mocking. Of course this is a very simple implementation, but it’s to show how to mock things out. For more advanced scenarios you should check the TypeMock manual.

Now let’s see how we would retrieve the same data with LINQ.

This is a lot less code. When we want to mock this out, we again use a recorder and just use the same code. However LINQ to SQL returns an IQueryable collection of Trainer objects. You can’t use recorder.Return(someList.AsQueryable()) inside the recording-block because then the AsQueryable would be mocked out as well. So we have to prepare the collection of trainers in advance.

You can see I prepared the fakeTrainers collection in advance, start recording and set the return value to the prepared collection. I then actually execute the code inside my tested class and assert that everything’s as expected.

The new pc

How about this, a pc in/on a napkin to use, read, write, collaborate with and more…

As you see in the picture on the left, there are enough in the holder and you can grab one to work with. Or each member of the team grabs one and start drawing out ideas and exchange napkins to share ideas and work them out more.

When you combine napkins you can create larger surfaces and present something to the team. The idea sounds awesome and I can only hope something like this will become reality. For now, it’s just an idea from a contest. Unfortunately.

PDC08 : Meet me in Los Angeles

Unit tests are for functionality, not code!

Marco mailed me this morning with the following sentence

Unit tests are meant to test functionality, NOT code! That means if you write your unit tests after the fact, you’re probably not focusing on the functionality.

This comes from two weblogs that have some unit testing comments. Jason Young posted the sentence and he refers to Obishawn who also has something to say. Why I’m writing this post is for two reasons. Or three actually. The first reason is that I liked the quote. The second reason is that Obishawn tries to prove that you should even test properties, something not many people do. But his argument is that it can grow to something that you definitely would want to test, so you should have a test in place to test the functionality. He also states that you should not trust your framework and although he’s probably right, I wouldn’t test my properties because I don’t trust the framework. If that’d be the case, it’d probably be enough to test a single property because with that I’d have tested them all. I know the .NET Framework has its bugs, but I hope to find these when writing tests that target my own code functionality.

Anyway, Obishawn also provides a few lines of code to prove you should test properties. I have written a small piece of code to expands on this a bit. There are three errors in it and maybe you can spot them. Although these are extremely simple (once you know which ones I mean) it’s an example of why you should seriously consider writing tests for all your code functionality.

Stopwatch snippet

A little snippet that I use from time to time when I need information on how long something takes. Type ‘sw’ (without the quotes) and tab-tab.

Installation is easy, just create a file called “sw.snippet” in your %Documents%\Visual Studio 2008\Code Snippets folder and paste the following in the file. You can use it immediately without restarting Visual Studio.

Office Live Workspace

You might know that I’m quite the Microsoft addict. While a lot of people are very sceptic with everything Microsoft releases, I tend to have a positive feeling for everything Microsoft releases, at first. After some experience, I might hate or love it, or just don’t use it because I don’t feel the need for it. Microsoft Sync, Parallel extensions and many more products and frameworks; after I get my hands dirty with it I’ll decide if it does any good for me or not.

About Office Live Workspace, I know there are many alternatives to it but I really want to give this a change. Everything looks good (I almost always like Microsoft GUI's), looks familiar, has a nice Office plugin and some other benefits. And hey, it’s a Microsoft product! ;-)

I just read they released new languages and that May was a very hectic month for them. But I seriously can’t believe why they don’t introduce folders. Everyone is crying out for folders but instead of folders, we get more languages and other stuff. So I thought, let’s see when they’ll introduce folders and went to their blogs. Of course (?) you have to login to place a comment. So I click the little Passport (or Windows Live ID) login icon at the top-right corner. But I get presented a login/registration screen. First thing I thought was that this was some phising attempt for my Windows Live ID username and password. Why use the icon and have a different registration system. Heck, why a different registration system at all? So I left the blogs and decided to write a long and boring post on my own weblog. And guess what, anonymous comments are enabled! :)

Anyway, I’ve registered for a workspace months ago and would really like to use it, but haven’t done so yet. Simply because of the lack of folders. I’m not even going to upload a small amount of folders to later find out I have to move every single one of them via a web interface.

Please introduce folders into Office Live Workspace! Thanks.

Windows Live Writer and ZoomIt

Two tools I absolutely love!

Windows Live Writer
A new version was just released, June 2nd. Download it here.

Sysinternals ZoomIt
Version 2.0 was released on May 28. I just downloaded that version myself and it has some nice features. However, I did not know about all 1.x existing features myself. I just saw a part of the TechEd keynote and noticed this guy was drawing rectangles and arrows. I thought : “What tool is this guy using? Can it be my favorite tool ZoomIt?” And yes he was!!!

• Draw a rectangle with the control key.
• Draw a line with the shift key.
• Draw an arrow with control and shift keys.

Now I did not know that! New features in 2.0 (afaik) are:

• Enable a clear sketch pad with the W (white) key or K (black) key.
• Save a drawing with CTRL+S
• Change pen width by holding ctrl and zooming with the mouse wheel.

Sw33t!!!

VS2008 DataDude and conditional deployment

This has taken us some time; depending on which environment you are, telling Visual Studio 2008 for Database Professionals Edition (or simply DataDude) what user it should use to deploy the SQL scripts, during an automated build. We're working with Windows XP users, Windows Vista users and Windows 2008 Server. As you might now, XP uses the "ASPNET" user to run IIS and Vista and 2008 use the "Network Service" user.

We're using FinalBuilder, a most excellent product, which in turn is using MSBuild and were trying to figure out how to pass variables to MSBuild, who should pass them to DataDude, which in turn would have to pass them to SQLCommand. Sounds difficult, but when you've figured it out, it's quite easy! :-)

The goal is to use "Network Service" when automated and let the user specify what user to use when running locally.

Here are the steps we took

1. We're going to use the variable TargetUser in the default MSBuild targets.
1. Open the solution with the DataDude project in it.
2. Right-click the project and select "Unload Project"
3. Right-click the now gray project and select "Edit <projectname.dbproj>"
4. Paste the following code at the bottom, just before the </Project> tag.
   
   

   <PropertyGroup Condition=" '$(Configuration)' == 'Default' ">

     <SetVariables>

       <Variable Name="TargetUser" Value="ASPNET" />

     </SetVariables>

   </PropertyGroup>

   
   
5. Now the default is to use the "ASPNET" user, which we want to influence. But just remember that this value is passed on to SQLCommand when building the project.
6. Change the ASPNET in the above variable to $(DatabaseUser), so you'll have the following.
   
   

   <PropertyGroup Condition=" '$(Configuration)' == 'Default' ">

     <SetVariables>

       <Variable Name="TargetUser" Value="$(DatabaseUser)" />

     </SetVariables>

   </PropertyGroup>

   
   
7. Now it'll insert whatever is in the DatabaseUser property. We'll still have to add it though.
8. Go to the top of your .dbproj and you should notice the tag <PropertyGroup> and a lot of properties beneath it.
9. Add the following property:
   
   

   <DatabaseUser>aspnet</DatabaseUser>

   
   
10. Now we have the same effect as in step 4, but we're providing it via a property. And properties we can change from the command-line with MSBuild!
2. Running MSBuild as follows would build the script and we would pass in "network service" as user.
   
   msbuild projectname.dbproj /p:DatabaseUser="Network Service"
   
3. However, we're not yet using the user in our scripts!!!
1. For this, open (or reload) your .dbproj file again.
2. Find the file Permissions.sql under the Scripts/Post-Deployment folder.
3. At the top you can see the "creat login" script for either your "aspnet" or "network service" user.
4. With the following script you can make it decide what to use.
   I removed some code for clarity. The important part is the IF statement. We defined the TargetUser in step 1.4 of this tutorial.
   
   
   
4. Save the script and you should be done.

If you're interested how to use this in FinalBuilder, here's how.

1. In your FinalBuilder project, add an MSBuild action and define your dbproj file as in the following image. Pay attention to the Targets that should be executed.
   
   
2. Now set the project properties on the last tab.
   
   
3. I've used a %AspNetWorkerUser% variable, defined in FinalBuilder self. Here's how...
4. Before building your project, add a "Define variable" action.
   Here's how I configured mine.
   I've used "MyAspNetWorkerUser" and set it as a user variable. Later on I copy this variable to a project variable. Just a personal preference. You do need a user variable though, but don't set a default value. We need this to be empty.
   
    
5. Define an "If ... then" action. Make sure that if your AspNetWorkerUser is empty, it executes the underlying action(s).
   
   
6. Now add a "Choose one" action. I've setup mine as follows:
   
   
7. The final result should be something like this
   
   

Good luck! :-)