Problem: In a T-SQL script, an exception occurs while a cursor is open, resulting in the cursor never being closed. But, the exception handling wraps the entire script, not just the cursor, so there is no guarantee that the cursor will be open if/when the CATCH statement is reached.

Solution: query the sys.syscursors view to see if the cursor(s) in question is still open:

BEGIN CATCH
     ...

     IF EXISTS (SELECT 1 FROM sys.syscursors WHERE cursor_name = 'MyCursor')
     BEGIN
	DEALLOCATE MyCursor
     END
     
     ...
END CATCH
		  

What’s wrong with this code? There are unnecessary lines. So? Why care about unnecessary lines? Because it shows that the programmer was not really thinking about what he was doing.

        MyObject obj = someList.Find(delegate(MyObject test)
        {
            if (test.Id.Equals(packageId))
            {
                return true;
            }
            else
            {
                return false;
            }
        });

Problem: you have a method that logs a message using the Microsoft Patterns & Practices Enterprise Library Logging Block, and you would like to write an automated unit test for it in NUnit (or Team System – solution is easily adapted). Logging to a flat file doesn't work; the file is still open when you try to read it to verify that the message has been logged. Logging to the database doesn't work; it seems the log isn't written to the database immediately. And so forth. Is there an in-memory way of reading the logged message?

A few months after I first purchased it, I am still reading xUnit Test Patterns. Been reading a few pages every day – now on page 590 with a few hundred to go!

I have finally arrived at the point where the author describes the pattern Test Specific Subclass (TSS). This is a pattern we have used extensively in our testing at the office, so that we can access protected methods in our classes. However, we stumbled upon it on our own, well before reading anyone else's suggestions on how to apply it. That's the nature of patterns for you.

We just upgraded our servers to support .Net 3.x, so at last I'm able to start migrating some of my code. I haven't taken a close look at all the features available yet, but one that caught my eye and initially excited me is automatic properties. However, I had two conflicting reactions:

1. This is great, I don’t have to create a private field and write getter/setter in a public Property anymore.
2. But then what’s the point of not just creating a public field and using it directly?

Well, this article addresses a primary benefit: this facilitates refactoring. If, for instance, we find later on that we need something more advanced than a simple get or set statement, then we can add it without breaking the interface. I'm sold.

One of my team members sent in the following piece of code, which is clearly intended to update the OrderNumber field for all objects in a List<T> of objects that match a particular productId. I took one look at it and thought "you can't do that!". But then I let the automated test run to see what happens... lo and behold, it worked. And well it should, once I thought about it.

Coding Horror, almost two years back, christened a name for the principle variously known as "don't repeat yourself," "once and only once," etc.: Curly's Law. Excellent formulation of the principle. In sending this to my development team, I thought it would be useful to pull this from the abstract to the specific through a few questions:

Lately I've been working with my team to understand and utilize good automated unit testing strategies with NUnit. A code release I was inspecting revealed a couple of good points that seem worth expanding on: the importance of testing each layer, and the need to pay attention to code coverage. This is a rather facile treatment; for more in-depth reasoning and details, I recommend xUnit Test Patterns.