ploeh blog : Productivity

Test-Driven Properties

ploeh — Mon, 12 Jan 2009 11:26:00 GMT

In principle, defining properties (or fields, for that matter) while TDD'ing should be no different than defining methods. Again, the important part is to stay focused on the test at hand, and not become bogged down by implementation details.

Unfortunately, neither Visual Studio 2005 nor 2008 has a Generate property stub smart tag, so until the day arrives when we get support for such in our IDE of choice (and for the record: I have no idea about when this is going to happen), we'll have to resort to more primitive means:

Just reference the non-existing property and move on:

As you can see from the picture, my test code gets squiggly lines under the MyProperty property because this property doesn't exist (yet).

Once more, the important point is to move on and resist the urge to fix this immediately. Don't even waste memory (your own, that is) on the fact that you need to implement this soon; just forget about it right away. The compiler will remind you in due time.

This technique is a essentially what Michael Feathers calls leaning on the compiler, although the context is different.

Use The Generate Method Stub Smart Tag To Stay In The Zone

ploeh — Mon, 05 Jan 2009 11:53:00 GMT

Yet Another Zero-Friction TDD Article (YAZFTA):

When writing unit tests in the TDD fashion, it's important to stay in the zone and not get side-tracked by irrelevant issues. You need to avoid what I call mental context switching. Focus on writing the test and postpone all else to later, but make sure that you do it in such a way that you don't have to waste brainpower on remembering what you postponed.

One easy way to do this is by using the Generate method stub smart tag in Visual Studio:

As we all know, this will generate the following implementation in MyClass:

public void MyMethod()

    throw new NotImplementedException();

but since you already know that, you don't have to go look at it, and you don't even need to commit to memory that you will have to implement the method. When you run the test, it's going to throw a NotImplementedException, and that's all the reminder you need.

So just use the smart tag and move on. Right away, forget about the method you just created. Resist the temptation to go implement it immediately, no matter how simple it might be. Stay focused on writing the test.

You can use the same technique when it comes to evolving SUT API Encapsulation: Sometimes, I know that I'd really like a test helper method that can do something for me, but I have only a vague idea about how to implement it. In such cases, I just write the name of the method, use the smart tag and move on. This helps me stay focused on writing the test, and I can always come back later and implement the helper method at a more convenient time.

Assert Messages Are Not Optional

ploeh — Wed, 17 Dec 2008 15:08:00 GMT

...and now, in this week's episode of Zero-Friction TDD: Optional Assert messages that aren't optional anyway!

Actually, this piece of advice comes almost directly from the xUnit Test Patterns book, so I was in doubt whether I should post it all, but it bears repeating, and I guess I still have a few things to add.

The various Assert methods all have an overload that takes a message string that is basically just echoed to the Test Results list if the test fails, appended to the assertion's more generic message.

For example, this assertion

Assert.AreEqual<string>(expectedResult, result, "DoStuff");

will produce this output:

Assert.AreEqual failed. Expected:<ploeh>. Actual:<>. DoStuff

As there are also overloads available that does not take such a message string, it is tempting to treat it as optional. As far as the compiler is concerned, I might as well have written this:

Assert.AreEqual<string>(expectedResult, result);

which would have yielded this output:

Assert.AreEqual failed. Expected:<ploeh>. Actual:<>.

Not much of a difference, so it may seem quite redundant to supply this extra message.

Well, not only will I argue that it provides value, I will even go so far as to insist that you should treat it as mandatory. Here's the reason:

When one or more test failures appear in the Test Results window, my eyes naturally seek out the Error Message text, so it's very nice to have all the information I need present in the same context. All I really need is just a small hint that will jog my memory enough so that I know what I did wrong.

Please note that I'm not really talking about using the message in the initial Red/Green/Refactor development cycle. In this phase, I rarely read the test failure text at all - I only register that there was a failure, which was expected, since the code isn't implemented yet.

I'm talking about what happens when you refactor a code base with hundreds of tests. In such cases, I often inadvertently break existing tests, and my eyes immediately seek out the Error Message.

Imagine that this is the error message:

Assert.AreEqual failed. Expected:<ploeh>. Actual:<>.

All this really tells me is that in one of my tests (and I don't know which one yet), something was expected to have the value ploeh, but ended up having no value. That's not a lot to go after, so I will probably have to open the test and read it through to get enough context to know what I broke.

On the other hand, I've experienced that just a little extra message often provides just enough context that I immediately realize what I broke:

Assert.AreEqual failed. Expected:<ploeh>. Actual:<>. DoStuff

In this case, DoStuff is the name of the method being tested. It may seem hard to believe, but in most cases, this is context enough to help my brain figuring out what went wrong. Keep in mind that the test failure was a result of a code change that I just implemented, so my mind has a lot of context already, and it needs almost no help to make the final connection.

When I first encountered this guidance, I was sceptic, but after having worked with it for some time, I'm not going back. It has increased my productivity while refactoring, because I don't need to investigate failure causes quite as often as I did before.

Most developers dislike having to write this optional message because they feel that they ought to write a long piece of fluent prose. That's not the case: Just write a single cue that can trigger your brain at a later date. Normally, I just write the name of the method or property I'm testing - I find that I can easily do that and still stay in the zone when I'm writing my tests.

You are probably still skeptical, but try it out for a couple of months and see what you think!

Why Use AreEqual?

ploeh — Thu, 11 Dec 2008 11:55:00 GMT

This is a post in my Zero-Friction TDD series.

One of my colleagues recently asked my why I prefer Assert.AreEqual<T> over one of the non-generic Assert.AreEqual overloads for primitive types.

In most cases, I'm very happy with the C# compiler's ability to infer generic type arguments from the method call parameters, but this case is a little different.

Let's say you want to compare two strings. I always do it like this:

Assert.AreEqual<string>(expectedResult, result, "DoStuff");

This statement explicitly tells the compiler to use AreEqual<string>. However, if I omit the type parameter, type inferencing is not going to happen:

Assert.AreEqual(expectedResult, result, "DoStuff");

Instead of inferring the type parameter from the parameters, the compiler (correctly) selects the best matching overload, in this case, AreEqual(object, object, string).

When both the expectedResult and result variables are strings, this will still compile and work, but you just lost static type checking.

There are 18 overloads of AreEqual, but that still leaves many combinations where type inferencing will occur. Consider comparing two integers:

Assert.AreEqual<int>(expectedNumber, result, "Explicit typing");

Since there's no non-generic overload that takes Int32 instances, you could omit the type parameter and still arrive at the AreEqual<int> overload:

Assert.AreEqual(expectedNumber, result, "Implicit typing");

However, what happens if you change the type of result to a string? In the first case, you will get a compilation error, but in the latter case, the compiler instead selects the AreEqual(object, object, string) overload!

When you perform refactorings that change the type of one of the assertion variables, the tests will still compile if you rely on type inferencing, but may fail at run-time. With the refactoring support in Visual Studio, you may be changing the type of a property somewhere else in your code base without thinking about the test code at all. If you test directly against such a property in your AreEqual assertion, static type checking could protect you, but the non-generic overloads may introduce subtle errors in your tests.

Since test suites should be executed often, you might argue that you'll discover errors like that soon enough, but I'm a strong believer in fail fast, so I still rather prefer getting a compiler error than a run-time error in my test suite.

The easiest strategy is to not think about this at all, and just always explicitly define the type, so that's what I do: I always use AreEqual<T> and AreNotEqual<T> (except in special cases, but more about that later).

3 Is Many

ploeh — Mon, 08 Dec 2008 17:51:00 GMT

This is an installment in my Zero-Friction TDD series.

When I was a kid, my parents taught me that many is any number above ~~three~~ two*; they used the simple counting sequence one, two, many. This little story may make me seem like I was an incredibly dim-witted kid, but the point was obviously not that I couldn't count to more than three, but rather that, in many cases, unary and binary systems may be special, but as soon as you cross the threshold to three, you are dealing with a number that doesn't exhibit any particular characteristics.

Note: I'm not talking about number theory here. I'm sure someone will be able to tell me about all sorts of special characteristics of the number 3. Incidentally, three also seems to be a magic number in many cults and religions. That's not what I'm talking about either.

If you will allow me to further digress, studies have shown that some animals can count to both three and also higher numbers. This goes for humans as well: If I place a number of marbles/dice/glass beads/whatever in front of you, and you have to give me the number as fast as possible, you can probably do that without counting up to perhaps five or six. For higher numbers, you will have to count the items. Three is an instantly recognizable number by the human mind, but I'm not talking about cognition either.

As a colleague once told me: The hardest scale-out you can perform is going from one to two. Nonetheless, if you look at concepts such as active/passive failover clustering, it would seem as though going from two to three is also non-trivial.

However, once you have managed to deal with three of whatever it is you deal with, you are probably ready to deal with four, five, or even twenty-seven. To bring the topic back to code, at that point you are probably working with a list of some sort.

When testing against lists, 3 is a good Equivalence Class for many. If you have a list of three elements, you have distinct elements for the head, interior and tail of the list. You can perform meaningful sorts and filtering on such a list.

In fact, I usually find that I can reproduce most scenarios (as well as most bugs) with lists of three elements.

When writing unit tests, for maintainability the number 3 shouldn't just appear as a magic number in the test, so it makes more sense to define it as a constant somewhere, as in this, otherwise inane, example:

private const int Many = 3;

[TestMethod]

public void SumOfManyNumbersWillBeCorrect()

    // Fixture setup

    IEnumerable<int> anonymousNumbers =

        Enumerable.Range(0, MyClassTest.Many);

    int expectedSum = anonymousNumbers.Sum();

    MyClass sut = new MyClass();

    // Exercise system

    int result = sut.Sum(anonymousNumbers);

    // Verify outcome

    Assert.AreEqual<int>(expectedSum, result, "Sum");

    // Teardown

The only noticeable part of this piece of code is the Many constant, which is used in the test code itself. This is a good hint to the Test Reader that this test deals with many integers, without particularly caring about how many there are.

* Edit 2009.01.20

testmethod Code Snippet

ploeh — Mon, 01 Dec 2008 16:32:00 GMT

This is an installment in my Zero-Friction TDD series.

If you are a regular reader of this blog, you may have noticed a certain pattern in my unit test examples (like this one). This is because I always follow the Four-Phase Test pattern (which is a superset of the more well-know Triple-A (Arrange Act Assert) pattern), with a few code comments to denote the different phases (incidentally, in this case, I don't regard these code comments as Apologies).

Writing the skeleton of such a test (the TestMethod attribute, the method declaration, the four comments) is very repetitious work, and I got tired of it around the third or fourth time I had to do it. Therefore, I wrote a code snippet that, in essence, just generates this template:

[TestMethod]

public void Test()

    // Fixture setup

    // Exercise system

    // Verify outcome

    Assert.Inconclusive();

    // Teardown

From there, you are ready to go ahead and fill in the blanks. It saves me a bit of typing for every test I write and allows me to get started faster with formulating the actual value-adding code, while the structure reminds me to write good and maintainable tests.

I've been using this code snippet for more than a year now, and although I've considered many enhancements to it, I've always felt comfortable with the versatility that this simple implementation provides.

For your convenience, I've attached the code snippet to this post: Just download it and put it in your <Documents>\Visual Studio 2008\Code Snippets\Visual C#\My Code Snippets folder. Now you can just type testmethod and expand the snippet, and you have a structured Four-Phase Test ready to be implemented.

Once more, it saves you a bit of mental context switching, and you can focus on writing the test code that really matters.

Ignore Irrelevant Return Values

ploeh — Fri, 21 Nov 2008 15:56:00 GMT

This is an installment in my Zero-Friction TDD series.

Sometimes, you don't care about the return value from a particular operation. The simplest example is if you want to check that creating a new instance of a specific type will throw an exception if supplied with wrong parameter values:

[ExpectedException(typeof(ArgumentNullException))]

[TestMethod]

public void CreateWithNullTextWillThrow()

    // Fixture setup

    int anonymousNumber = 8;

    string nullText = null;

    // Exercise system

    new Plop(anonymousNumber, nullText);

    // Verify outcome (expected exception)

    // Teardown

In this example, even though the new operation is supposed to return a value, we don't care about it, since we only want to test that the correct exception type is being thrown. To save myself from having to stop and think about a variable name (even though in this case, I'd just have used sut), I prefer to not declare and assign the variable at all.

In general, I believe that APIs should follow the principle of Command-Query Separation, but sometimes it makes sense to break this rule. When you have an operation that both return a value and have side-effects, testing the side-effect via state-based testing doesn't require the return value.

Imaging that you have a method with this signature:

public object CommandQuery(int number)

Testing the side-effect may look like this:

[TestMethod]

public void CommandQueryWillUpdateNumberProperty()

    // Fixture setup

    int expectedNumber = 89;

    int anonymousNumber = 11;

    string anonymousText = "Anonymous text";

    Plop sut = new Plop(anonymousNumber, anonymousText);

    // Exercise system

    sut.CommandQuery(expectedNumber);

    // Verify outcome

    Assert.AreEqual<int>(expectedNumber, sut.Number, "CommandQuery");

    // Teardown

Notice that I've ignored the return value of the CommandQuery method.

Save yourself the time and effort it takes to declare and assign variables if you don't use them anyway.

Anonymous Variables

ploeh — Mon, 17 Nov 2008 15:32:00 GMT

This post is an installment in my series on Zero-Friction TDD.

Often when writing a unit test, the SUT's API will force you to create objects that you really don't care about. As an example, take a look at the signature of this constructor:

public Plop(int number, string text)

To create an instance of the Plop class, you must supply both parameters, but you may not care about their values. You can't just pass in null as the text parameter, because the constructor checks for this and throws an ArgumentNullException if you do. In other words, you are forced to create some non-null text to pass to the constructor, even if its specific value is totally irrelevant to the test at hand.

That sounds a lot like the description of a Dummy, except that such variables are taxonomically different because they aren't Test Doubles. In xUnit Test Patterns, Gerard Meszaros also discusses Anonymous Creation Methods as one way of creating variables like these, so I've lifted this terminology to call them Anonymous Variables.

When naming such variables, I prefix the variable name with anonymous to indicate that I don't really care about the value.

[TestMethod]

public void CreateWillExposeNumberAsProperty()

    // Fixture setup

    int expectedNumber = 4;

    string anonymousText = "Anonymous text";

    Plop sut = new Plop(expectedNumber, anonymousText);

    // Exercise system

    int result = sut.Number;

    // Verify outcome

    Assert.AreEqual<int>(expectedNumber, result, "Number");

    // Teardown

Naming the text variable anonymousText instead of just text or something similar probably doesn't save me much context switching, but it's a good help for the Test Reader because it clearly indicates that we don't really care about this value.

Even though it's redundant, I also type in Anonymous text as the string value, although this could really be anything. However, it saves me the trouble of coming up with something else.

The same pattern can be used if we want to test the text instead of the number

[TestMethod]

public void CreateWillExposeTextAsProperty()

    // Fixture setup

    int anonymousNumber = 3;

    string expectedText = "Anonymous text";

    Plop sut = new Plop(anonymousNumber, expectedText);

    // Exercise system

    string result = sut.Text;

    // Verify outcome

    Assert.AreEqual<string>(expectedText, result, "Text");

    // Teardown

With numbers, the value itself can contain no hint of its origin and usage (like a string can by saying I don't matter), so the name anonymousNumber is the only clear indicator of the number's purpose. It also helps clarify what may otherwise look like a magic number: Why is the value 3? The name gives us an indication that it doesn't matter, and it might as well have been some other value. Without that hint, the Test Reader might have to spend more time before determining whether or not the number 3 carries any particular connotation in this context.

Notice that even though the text variable isn't an Anonymous Variable any more, I've kept the text Anonymous text as the string value, since I don't really care about the explicit value, but only about the relationship between input and output. Again, this is a help for the Test Reader - and remember: That may very well be you six months into the future.

In terms of avoiding context switching when writing tests, this tip falls into the Almost-Not-Worth-It category, but if you combine it with the assistance it provides the Test Reader, it is certainly a valuable habit to pick up.

Naming Direct Output Variables

ploeh — Fri, 14 Nov 2008 12:38:00 GMT

In my series of Zero-Friction TDD tips and tricks, it's time to look at naming Direct Output variables.

[TestMethod]

public void DoStuffWillReturnMessage()

    // Fixture setup

    string expectedResult = "ploeh";

    MyClass sut = new MyClass();

    // Exercise system

    string result = sut.DoStuff(expectedResult);

    // Verify outcome

    Assert.AreEqual<string>(expectedResult, result, "DoStuff");

    // Teardown

As you can see, I use the name result for the return value of DoStuff, and I always use that word, irrespective of its type or other circumstances. Whether you prefer result or another word is not important; the salient point is that by always using the same word, you save a context switch (because you don't have to stop and think of a good name) and thereby incrementally increase your productivity.

Zero-Friction TDD

ploeh — Thu, 13 Nov 2008 14:52:00 GMT

Writing good code is difficult. Unit tests are written as code, so a corollary to the first sentence is that writing good unit tests is also difficult.

TDD (particularly if you interpret the last D as Design) carries this challenge in abundance, since you ought to be focusing on designing your SUT, but you might end up spending a lot of energy on ensuring the readability and maintainability of the tests themselves.

The goal is Zero-Friction TDD. To me, this means that you should be able to focus entirely on designing the SUT. Writing the test should present as little productivity friction as possible.

Writing a test will always require some attention to the test itself, but any trick you can use to take your mind off the test will enable you to better focus on the SUT. Every time you have to think about how to write the test instead of how to design the SUT, you make a context switch, and each of these cost you productivity.

This means that even if a given optimization strategy may seem insignificant in itself, a lot of these can go a long way towards keeping you in the zone.

I've already posted one example, where I describe a few arguments for naming SUT test variables sut. The argument I didn't present is that it frees you from thinking about a good name for the variable. In the context of that post, such an argument would have seemed trifling, but in the broader context, it saves you from one context switch and enables you to move on with writing the test.

In future posts, I will share other tricks you can use to focus your mental energy on designing the SUT, while still writing good unit tests.

Update: Posts in the series:

Update: While I was publishing this series of posts, my employment at Microsoft came to an end. Please see my new blog for an updated list of Zero-Friction TDD posts.

Vote For Better TDD Support in Visual Studio 2008

ploeh — Fri, 18 Apr 2008 11:13:00 GMT

Eric Jorgensen has created a Microsoft Connect item asking for better TDD support in Visual Studio 2008. If you also miss the green (sometimes red) progress bar and other UI elements of NUnit and similar tools, and think that Visual Studio should have a UI that supports TDD better than it currently does, please go to the item and give it a favorable vote!

Automatically Generating LINQ To SQL Models From T-SQL

ploeh — Fri, 11 Apr 2008 00:13:00 GMT

With LINQ to SQL, a couple of questions quickly arise:

Since you can create a data model directly in Visual Studio, where's your authoritative definition of the database?
If you generate a data model from your database, how do you maintain the model if you have to tweak it?

The first question is pretty easy to answer: Since T-SQL can express a lot more about your database than can a LINQ data model, T-SQL should be your authoritative definition. For example, you can define clustered and non-clustered indexes in T-SQL, but not in LINQ to SQL (as far as I know).

Since T-SQL should be your authoritative database definition, you can generate a LINQ to SQL data model from your database. Unfortunately, there's no tool that I'm aware of that you can point directly at a set of T-SQL scripts and have it generate a .dbml directly, so you have to have a SQL database your tool can use.

The next question that pops up, then, is how do you ensure that this particular database instance reflects your T-SQL script?

The answer to that question is to create the database just before you run your tool. If you've been following my posts on data access testing, you will know that I'm not in the habit of having specific databases on my machine - I have a database engine (SQL Server) on my machine, but no databases. When I run a test suite, it first creates a completely new test-specific, temporary database, runs all the tests, and finally deletes the database again.

When generating or updating the .dbml file, you can follow the same approach, and you can automate the whole thing in a script. The script should perform the following steps:

Create the database based on the authoritative T-SQL scripts.
Generate the data model using Sqlmetal.exe.
Modify the .dbml file if you need to customize it (such as changing generated property names, etc.)
Delete the database.

Using my HoneySqlAccess project as an example, let's have a look at how to accomplish this. I'll use a Visual Studio 2008 PowerShell to script this, but you can also do it in a Command prompt if you can find a command-line XSLT processor.

The first step is to create the database itself, complete with schema. Since I use an Installer for this, I do it with InstallUtil, but you could also execute a set of T-SQL scripts by using SqlCmd:

InstallUtil /ConnectionString="Data Source=localhost;Initial Catalog=HoneyTemp;Integrated Security=True" bin\Debug\Ploeh.Samples.HoneySqlAccess.dll /LogFile=

The main thing to notice here is that I create a new database called HoneyTemp.

The next step is to create the LINQ to SQL data model. For that purpose, we can use a tool called Sqlmetal:

SqlMetal /server:localhost /database:HoneyTemp /dbml:OriginalHoneyDB.dbml /namespace:Ploeh.Samples.HoneySqlAccess /pluralize

This creates the file OriginalHoneyDB.dmbl from the database HoneyTemp that was just created in the step before.

If you are inclined to accept the generated data model as is, you can just include the file in your project and go ahead and use it. When you add a .dbml file to Visual Studio 2008, it will automatically set it up with the MSLinqToSQLGenerator custom tool, which will cause it to autogenerate .NET code for you.

In many cases, however, you will want to tweak the model a bit (I'll get back to that later). Since a .dbml file is just an XML file, the most flexible approach is to apply an XSL transformation. Since this is PowerShell, I can just use .NET objects directly:

$transformation = [System.IO.Path]::Combine((Get-Location).Path, "ModifyDataModel.xslt")

$originalDbml = [System.IO.Path]::Combine((Get-Location).Path, "OriginalHoneyDB.dbml")

$dbml = [System.IO.Path]::Combine((Get-Location).Path, "HoneyDB.dbml")

$xslt = New-Object System.Xml.Xsl.XslCompiledTransform

$xslt.Load($transformation)

$xslt.Transform($originalDbml, $dbml)

This part of the script uses the ModifyDataModel.xslt transformation to create the HoneyDB.dbml file that I can then go ahead and include in my Visual Studio project.

Left is only a bit of clean-up:

del $originalDbml

InstallUtil /u /ConnectionString="Data Source=localhost;Initial Catalog=HoneyTemp;Integrated Security=True" bin\Debug\Ploeh.Samples.HoneySqlAccess.dll /LogFile=

The OriginalHoneyDB.dbml file is just for transitory use, so can be deleted. The last line is just my (Installer-based) way of removing the database from my system again (notice the /u switch to uninstall).

Most of this script just calls .NET SDK command-line utilities, or, if you want to use SqlCmd for executing T-SQL scripts, tools from the SQL Server Client Tools installation. The only part that isn't going to work in cmd.exe is the XSLT processing part, but if you can find a suitable command-line XSLT processor (there are several free ones available), you can mimic this script in a .bat file as well.

The last thing I want to show you is a couple of snippets from the XSL transformation.

Since the transitory database was called HoneyTemp, Sqlmetal creates a DataContext called HoneyTemp. That is obviously not an acceptable name, so it should be renamed to something better, like HoneyContext:

<xsl:template match="dbml:Database">

  <xsl:copy>

    <xsl:copy-of select="@*" />

    <xsl:attribute name="Name">HoneyContext</xsl:attribute>

    <xsl:apply-templates select="node()" />

  </xsl:copy>

</xsl:template>

Another modification I wanted to do was to rename Bee.ID to Bee.Id, since Code Analysis would otherwise complain about the naming of the ID property. On the other hand, I didn't want to change the column name in the database from ID to Id, so a mapping is in order. LINQ to SQL supports that scenario by adding a Member attribute to the appropriate Column element, so that's what's going on here:

<xsl:template match="dbml:Database/dbml:Table/dbml:Type[@Name = 'Bee']/dbml:Column[@Name = 'ID']">

  <xsl:copy>

    <xsl:apply-templates select="@* | node()" />

    <xsl:attribute name="Member">Id</xsl:attribute>

  </xsl:copy>

</xsl:template>

Although this recipe may seem complex, it's fully automated and sure beats having to do a series of manual steps. Whenever I need to change the database schema, I can just edit my T-SQL scripts and then run my PowerShell script to automatically update my LINQ to SQL data model. If I wish to do some customization of the model, I can add or edit those in the XSL transformation. Each schema item is defined in one, and only one, place.

Since the files involved in the example are a bit complex, I've attached a downloadable sample to this post. As always, this is only sample code and is provided as is, etc.

Visual Studio 2008 PowerShell

ploeh — Wed, 09 Apr 2008 22:24:00 GMT

Ever since I first saw a demo of PowerShell some five years ago, I've been wanting to use it for development work; such as automating code generation or whatever other task for which small scripts are needed. It's such a powerful environment, and I simply love the fact that it's based on .NET and that you can easily create new Cmdlets! What's been holding me back so far is that none of the tools I regularly use (SvcUtil, InstallUtil, etc.) are available in the default shell.

Sure, I could manually add the necessary directories to the shell's path, but since there's always been a Visual Studio Command Prompt (driven by vsvars32.bat), that seemed to me like unnecessary duplication of effort. Luckily, Chris Tavares has a solution! ...or, that's at least what I thought when I first read his post.

Unfortunately, it didn't work for me. While I'm sure that Chris tested his solution, my registry simply doesn't contain the InstallDir node that he uses. Whether that's because I'm running on Vista x64 (which causes many funky issues from time to time), or my Visual Studio installation is just plain weird, I don't know... At least, Chris' post solved the most difficult problem for me: Getting the vsvars32.bat path and other environment variables into PowerShell.

On every machine that I've ever had Visual Studio installed, there's always been an environment variable called VS90COMNTOOLS that points to exactly the folder containing vsvars32.bat, so why not use that instead of the registry approach?

While I kept Chris' Get-BatchFile function unmodified, I reimplemented the VsVars32 function as:

function VsVars32()

    $vs90comntools = (Get-ChildItem env:VS90COMNTOOLS).Value

    $batchFile = [System.IO.Path]::Combine($vs90comntools, "vsvars32.bat")

    Get-Batchfile $BatchFile

    [System.Console]::Title = "Visual Studio 2008 Windows PowerShell"

As you can see, getting the correct path to vsvars32.bat is as simple as extracting the VS90COMNTOOLS environment variable and then using Path.Combine to construct the full path to the file.

To get a Visual Studio 2008 PowerShell (as an equivalent to the Visual Studio 2008 Command Prompt), I combined it all in a vsvars32.ps1 file. To run the script file and keep the shell open, you need to open it like this, since double-clicking a .ps1 file will just open it in Notepad:

powershell.exe -noexit <path>\vsvars32.ps1

where <path> indicates the path to the vsvars32.ps1 file. To make it easier to quickly open a Visual Studio 2008 PowerShell, I created a shortcut with this command, and added the shortcut to my Start menu. Now I can simply type Visual Power in my Vista Start menu search box, and I then have instant access to my Visual Studio 2008 PowerShell.

As a convenience to you, my dear reader, I'm attaching the script file for your reuse - use at your own peril.

If you are new to PowerShell, note that you must change your execution policy to RemoteSigned or less (or sign my script with a certificate you trust) to be able to run scripts at all, and that you probably also need to go to the file's properties and unblock it, since you downloaded it from the internet.

Update: You can also move the VsVars32 (and corresponding Get-BatchFile) function into your profile.ps1, and just call VsVars32 from your vsvars32.ps1 file. That enables you to use VsVars32 from other scripts without having to explicitly open a Visual Studio 2008 PowerShell.

Race Troubleshooting Using The Console Output In VSTS

ploeh — Sat, 06 Oct 2007 22:13:00 GMT

It must be my week of discovering the obvious. The other day I was troubleshooting a race condition in my code. I had a unit test that faithfully reproduced the error, but just looking at the code involved didn't produce any sudden insights into its reasons. The nasty thing about race conditions (and multi-threaded code in general) is that you can't debug them, since the debuger influences the race.

Sometimes, you can troubleshoot race conditions by tracing strategic points in the code, and sometimes it doesn't work, since even tracing statements influence the race. In my particular case, tracing didn't disrupt my race condition, so the only problem left was how I could view that output as easily as possible. Since I was using VSTS unit tests from within Visual Studio 2005, I was hoping my Console output would be in the Output window, but no such luck. Then, in a rare case of inspiration, I double-clicked on the test in the Test Results window and got a window similar to this one (which is a mock-up, I admit):

Notice the highlighted Standard Console Output.

It's so simple that I wonder I never discovered this feature before, but now that I know it exists, I know how to troubleshoot race conditions reproduced in unit tests the next time I have to deal with multi-dreaded code :)

Agile Proves Effective Once More

ploeh — Fri, 31 Aug 2007 11:14:00 GMT

Christian, one of my old (and present) collegues, has just posted about his team's latest accomplishment, shipping six months ahead of time! I'm sure that the team consists of a bunch of very talented people, but I'd also venture a guess that their adoption of agile methodologies has a lot to do with it.

If only more development organizations would adopt agile methodologies... At least, such a result as shippng six months earlier should make some people stop and think about their current way of creating software :)

Let's have more of that, and congratulations to Christian and his team!