Skip to main content

78 posts tagged with "dotnet"

View All Tags

Test Naming Convention

· 3 min read

Historically I've advocated naming test methods after the method under test, in order to help find the tests when you need to modify them. Growing Object-Oriented Software, Guided by Tests has shown me that this is a relic of a code-first mentality rather than good application of test driven development, primarily in the section "Test Names Describe Features" (ch 21). "Test driven" development implies that we do not know the name of the method we're going to test. But we do know the functionality (feature) that we are going after, and that knowledge should be used when writing out a test name. For example:

A Recipe for Setting Up Automated Test Projects

· 5 min read

Assuming that you are already sold on the notion of automated testing, it can be useful to put a little thought into how projects will be setup. There are many approaches to this; my approach is based on experience, the wisdom in xUnit Test Patterns, and standard coding best practices. I will try to keep this language agnostic, though my examples will be in C#.

What about uint?

· One min read

I'm writing a class with several methods that take integer input. The input values cannot be less than zero. Since we're not on .Net 4.0 yet, I'm manually writing code contracts (that is, my functions check preconditions), e.g. before doing anything else, I write something like…

if (sequenceNumber < 0)
{
throw new ArgumentOutOfRangeException("sequenceNumber", "Sequence number must be 0 or greater");
}

This got me thinking: why don't we ever use unsigned integers? Seems like having a uint would better communicate the requirement, and would simply not allow a negative number. The main answer seems to be that casting between uint and other data types, which is inevitable, is ugly. And that uint is not CLS compliant. Even though I'm not trying to write CLS-compliant code at the moment, I think I'll stick with int — because that is our existing convention, and I don't see enough reason to change the convention.

Change HostType["Pex"] to HostType["Moles"]

· One min read

Once again I've learned the hard way that it pays to read the release notes. After installing Pex v0.91.x, suddenly I was having trouble running my tests in a particular solution. It has been driving me nuts - Visual Studio was throwing "object reference not set to an instance of an object" errors every time I tried to run tests, and the Test View was refusing to load any test names.

Finally, I noticed that I had a few tests that were still instrumented with HostType "pex" instead of "moles". I changed these around, and still got the error. Closed Visual Studio, restarted, and voìla, the tests can run, and Test View is populated again.

Pex and Moles - Release Notes

safnet logo