177 posts tagged with "technology"

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.

Something I was reading this weekend pointed out that leaving braces out of a one-line block can be dangerous. For instance, it is correct to code the following (and I do it all the time!)

if (someCondition)
    this.doSomething();

We had a horribly pernicious timeout problem recently. It was occurring in a .Net 2.0 application written to retrieve reports from SQL Server 2005 Reporting Services via its web services interface. The query behind the report was a bit large, but typically would run under 30 seconds. We had judged that new indexes were out of the question because of their impact on the already slow program that loads the key data. All of the sudden, we started getting continuous timeouts. After a couple of days, the underlying query was up to 15 minutes execution time!

In the end multiple interacting problems had to be solved in order to get the reports running properly. For the past few weeks they've been running without a hitch.

I once read that .Net's String.IsNullOrEmpty performs better, and is safer, than just checking to see if a particular string has an empty value. I.e. replace if (myString == "") or if (myString.Equals(string.Empty)) or if (myString.Length == 0) with if (String.IsNullOrEmpty(myString)). It is certainly easy to read, and points out that the string should really be checked for null value before doing anything else.

Problem​

you have an application that needs to trigger some process via SQL Server but don't want your main process hung up waiting. So you decide to setup Service Broker in order to make an asynchronous call, with the receiving service doing your work for you. You've read all about it, and tried it out after hours, but it didn't work. What gives?