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.
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.
Although very handy, C#'s foreach statement is actually quite dangerous. In
fact, I may swear off its use entirely. Why? Two reasons: (1) performance, and
(2) predictability.
As a Web developer whose formal programming training focused only on console
applications and simple GUI apps, it was not immediately obvious to me how to
update a (Windows Forms) GUI while a method was still running. Once I decided it
was worth the effort to learn how to do so, I was not surprised to find that it
is rather easy, using BeginInvoke().
You have some XML, and you need to validate it against a custom schema that you want to deploy with your .Net 2.0 assemblies. Issues addressed: opening the file and handling the schema validation.
The XmlSchema class contains a
Read
method that takes a stream as a parameter. Nicely matching up to that, you can
open a stream from an embedded resource (dead link removed; SF 2025).So, embed
the schema. In Visual Studio's Solution Explorer, right-click the schema file
and choose properties. Change the Build Action to "Embedded Resource".
you have image data from an HTML e-mail, but don't know what to do
with it. When you save it to disk it comes out with a weird string instead of binary data.
pretty simple, you just have to know the terms. This string of
data is actually Base64 encoded, which means that the binary data has been
converted to a text string for easy transmission over text protocols. .Net
Developer's Journal (dead link removed; SF 2025) has a good full explanation.
All you have to do is convert the string over to a byte array using
Convert.FromBase64String, then save your new byte[].
You want to run NUnit tests in a class library (dll). These test rely on an application configuration file (app.config) for some settings, i.e. custom appSettings or database connection strings. The code compiles and runs fine by itself, but your unit tests always fail. Attaching the Visual Studio debugger to NUnit and stepping through the code, you see that the config seems to be ignored.
