Eric Sink, whose company, SourceGear, publishes a source control product called SourceGear Vault, announced that they are now offering a single user license for $49.

He has an excellent article about why to use source control on projects with one developer and a follow up.

To his list of reasons, I’d add these:

• It enables Daily Builds.  You can’t build on a clean machine from the source on your drive. You need there to be an official, working version of the source.
• It enables bug fixes to released versions. Using labeling and branching features, you can fix a bug in a released version to a user without also giving them every change you’ve made since then. This is important no matter how many developers you have.
• It enables binary search bug fixing. Outlined in this Joel On Software article, it’s simply a way of finding a bug by systematically trying each archived build until you find the one that introduced the bug.  Then you check the log entries to see what you did.

Eric sells the benefits a little short, I think, but any company with one developer is unlikely to shell out a lot for source control, so the price is probably right, and there’s always that hope for a second developer.

I’m preparing a presentation on unit testing in .NET (using NUnit). Unit Testing is generally non-implementation language specific. The original SmallTalk framework and the popular jUnit Framework for Java have nearly identical designs. The same is true for CppUnit (for C++) and every other unit testing framework I’ve looked at. Since .NET languages support all of the language features necessary to implement this design, I assumed that it would be the same—and for NUnit 1.0, that was the case.

NUnit 2.0 takes it further. The developers correctly realized that .NET offers some features that can automate some of the tasks in unit testing, and took advantage of them. This “breaks” consistency with other unit testing frameworks, but for a good reason, and it’s close enough to the others to not be a big problem.

The basic architecture of the xUnit Frameworks provides a base class called TestCase which you extend to contain the test methods. The framework requires you to write another class that builds a list of these classes into a TestSuite. In jUnit, this class typically looks like this:

import junit.framework.*;

public class AllTests
{
  public static Test suite() {
    TestSuite suite =
      new TestSuite(“All tests”);

    suite.addTest(
      new TestSuite(ReaderTest.class)
    );

    suite.addTest(
      new TestSuite(CommandTest.class)
    );

    return suite;
  }
}

Note that the method AllTests.suite() must be edited each time a test class is added. If you forget, you will get a false test success. If you’re writing tests first, you will notice this immediately—but it would still be nice not to have to write or maintain this class. NUnit 2.0 uses custom attributes so that the framework can discover all Test classes and call them automatically, and takes care of this manual task. In NUnit, instead of extending a TestCase, you use a custom attribute to mark the class as a TestFixture and add test methods to it (either marked with the attribute Test or named with the prefix “test”).  It looks like this:

namespace NUnit.Tests
{
  using System;
  using NUnit.Framework;

  [TestFixture]
  public class SuccessTests
  {
    [Test] public void Add()
    { /* … */ }

    public void TestSubtract()
    { /* … */ }
  }
}

There is no need to write an AllTests class, as .NET has features that allows the framework to discover this class automatically and run it. Kent Beck calls this an “idiomatic design”, one that takes advantage of language features, instead of porting the design from a language with less features, and is a good lesson for any type of language port.

Extreme Programming combines several practices into a well-defined software process. The goal of XP is to deliver features to the end user as fast as possible. Some of the practices are focused on quality, some on maintaining releasability, some on development speed and some on planning.

XP may seem daunting to you at first because it’s probably very different from how you work now. It’s also common for development teams to doubt the benefits of some of the practices and resist adopting them. Therefore, when getting started with XP, you will find it easier to migrate there in small changes, each one building upon the last and gaining confidence and trust in the process the whole way. If some of the practices aren’t right for your organization, you can still benefit from the others.

There are three XP practices which are easy to adopt and will provide immediate benefit. In addition, they don’t rely on other practices.

The first, Coding Standard, simply states that you should have a consistent naming and formatting convention for your code. Many organizations already do this and some languages (Java, Eiffel, C#) already have recommended coding standards. Your coding standard should not only be internally consistent, but also consistent with industry norms. This practice enables the Metaphor and Common Code Ownership practices.

The next, Unit Testing, is far less commonly used in non-XP shops, but no other XP practice is as easy to adopt and has as much immediate benefit as it does. Even if you are skeptical of XP, I highly recommend that you try Unit Testing and I will be spending a lot of time in this blog discussing why. Unit Testing enables Refactoring, Simple Design, Common Code Ownership, Continuous Integration, and other good practices.

Lastly, instituting Daily Builds will make your functional testing and deployment more consistent. This is also easy to adopt and has many obvious benefits. This practice enables Continuous Integration, Small Releases, and Customer Tests practices.

XP practices work best when combined, but it’s better to be successful at using some of them than fail when trying to use them all at once.

Once you’ve mastered these, pick among the enabled practices to take your process further. Practices focused on getting code to users will be most beneficial (Continuous Integration, Simple Design and Small Releases).

Here is a list of software processes that should be automated

1. Source control
2. Bug tracking
3. Unit Testing
4. Daily Build and Test
5. Deployment
6. Functional Testing (Black box testing)
7. Source Code Generation (from other sources — e.g. Databases)

I’ll be talking more about these soon.  The order is determined by what will give you the most benefit for the least additional work.

For some projects, it’s just inexcusable to not have automated deployment, and it will make sense to tackle that first. For most projects, it’s the development processes which are manual or semi-manual and need to be dealt with first.