For those of you struggling to understand the different approaches to testing being heralded in by the TDD community I strongly encourage you read the following article:

TDD Tests are not Unit Tests

Stephen does an excellent job of detailing the general purpose behind the testing styles and really clarifies for my why I tend to disagree with many of the assertions about unit testing from the TDD community. First let me say I don’t do TDD, and generally I fundamentally disagree that it produces better software.

What I do believe in is testing your code via unit tests (call it integration testing, acceptance testing, whatever). I have been testing code via NUnit since 2002. Perhaps I may be set in my ways, I just can’t seem to join the TDD ‘gold rush’. There might be a reason for TDD (test before code) if you are doing one of the following:

  1. Giving one or more interfaces to a Jr team member for implementation
  2. Working tightly with a remote team member
  3. ??? Ok, short list because I can’t find any other reason ???

Maybe I’m crazy, but ensuring product/component stability and a general confidence in changes are the only goals for me. With one side benefit of either learning an API or providing a sample usage of one.

 

http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

This wiki was developed and published in a book available from O’Reilly Press. So far it’s a great read put together by the collective experiences of many seasoned developers. My own favorite so far is: Simplicity before generality, use before reuse.

I think the idea of capturing this all by wiki is entirely awesome. I just wish they would keep it going, I’m certain there is more than 97 things I should know ;)

BTW, Thanks to From 9 till 2 for bringing this to my attention.

 

To all those from Houston’s Alt.Net Open Space conf, greetings. I had a great time hanging out with you and sharing ideas.

For those that did not attend, you simply MUST check out an Open Space event. It was, without doubt, a very unique kind of conference. To take a look at some of the topics check out the wiki that was put up.

This was facilitated by Steven “Doc” List and he was simply awesome. Check out his blog he is a really interesting guy. If I was still working at a large enough company I’d be clamoring for this guy to come and ‘show us how it’s done’. I’m confident he could provide benefit to any sizable organization in short order.

 

I found a related post over on CodeThinked entitled “Ten C# Keywords That You Shouldn’t Be Using“.

He discusses several of the more obscure C# keywords and why they should be used only after careful review and understanding. I like all of them except the one on the keyword ref. I find at least one example of when to use it acceptable:

	static void DisposeOf<T>(ref T value) where T : IDisposable
	{
		if (value != null)
			value.Dispose();
		value = null;
	}

Though when using this approach I usually create the routine for a specific type rather than using a generic; however, it still holds to prove as a non-tragic use of ref.

 

Last night I published a new version (1.0.401.118) of the source out to the google code repository. A few small fixes/enhancements to some of the existing shared code but for the most part this is adding the additional library: CSharpTest.Net.Library. The library includes several things I’ve been using a for a while on a project I’m trying to clean up. Of particular note this includes a System.Configuration.ConfigurationSection to handle a userSettings element that is similar to appSettings. I’ll cover the details of the additions one at a time in future posts.

 

If statements in code, need I say more. I know most of you out there get it (and yes, if statements are not the only way to branch code, but they are the worst offender IMHO). I just seem to be lucky enough to continue to find code riddled with if statements. Why don’t these [...]