I like unit tests. It's cool to be able to try out little bits of your code, and make sure the small parts work before you try making it do larger things. It's good stuff.

But by god - does it have to be so poorly documented?

In this case I'm looking at NUnit.Util. This is part of the standard NUnit install, and it contains a bunch of classes - and no documentation on them. I've done searches through google - no documentation found.

Does this stuff get used?

What I needed: A way to trap output that is supposed to go to the console so I can make sure that something that writes to it is actually writing what I wanted.

What I eventually did: I took the NUnit.Util.ConsoleWriter, and inherited from it as below. Then, I passed it in as a TextWriter, which my console app would write to.


using System;
using System.Text;
using System.IO;
using NUnit.Util;

namespace moCSCXIImport.Tests
{
///

/// Summary description for MockConsole.
///

public class MockConsole : ConsoleWriter
{
private StringBuilder TextBuffer;

public MockConsole(TextWriter console) : base(console)
{
TextBuffer = new StringBuilder();
}

public override void Write(char c)
{
TextBuffer.Append(c);
base.Write(c);
}

public override void Write(String s)
{
TextBuffer.Append(s);
base.Write(s);
}

public override void WriteLine(string s)
{
TextBuffer.Append(s);
TextBuffer.Append("\n"); // newline
base.WriteLine(s);
}

public string TextWritten
{
get { return TextBuffer.ToString(); }
}

public long GetTextLength()
{
return TextBuffer.Length;
}

}
}


But I'm sure someone's done something like this before. But why couldn't I *find* it?

Visual C# 2005: A Developer's Notebook
By Jesse Liberty
O'Reilly (IBSN: 0-596-00799-X)
Price: $29.95

One of the difficult parts of keeping up to date with the newest version of a programming language is knowing when it's worth your time to start learning it. Too early, and you're frustrated by the parts that don't work yet and focused on learning features that may not be kept. But wait too late, and you're too busy playing catch up to keep track of the wonderful new things people are making with it. So, a book like this is a great help to a programmer needing a little guidance at finding the new pearls amid the old.

Mr. Liberty goes through different parts of the Visual C# landscape, starting with simple language features, and then moving on to changes in the IDE, new features for windows programming, the new powerful features for ASP.NET programming, and then closing with the changes to ADO.NET and other ways of handling data. He doesn't go into deep depth – instead, he tells you about a new feature, shows you using complete code samples how that new feature can be implemented, and then tells you how that works and where you can go on the web to find out more on that subject. So, for example, in the section on Generics he goes into how the generic List<> object works, and then shows how to make a generic linked list of your own, as well as generic Enumerators. But he leaves it up to us to explore a little further to learn more about the other sorts of generics there are and how they might work. It begins by instructing on a topic, and then guides you to learn more, a good feature for teaching the reader. This is not a reference – it's a guide.

Mr. Liberty's writing style is relaxed without being informal to the point of silliness. He assumes the reader is intelligent and already knows a fair amount about C#, and instead of holding your hand, he just points out the way. I strongly recommend this book for a programmer looking to keep his skills up to date with the move to .NET 2005.