Monday, January 31, 2005

Design Patterns

[This was originally posted at]

"Design patterns are recurring solutions to software design problems you find again and again in real-world application development." ( Using design patterns in your code provides structure, good practice, familiarity for other developers, and greater confidence that you're doing it "the right way".

In my experience, many .Net developers have never needed to consciously use patterns because .Net is simple yet powerful enough to get away with it. However, as clients demand better applications, design patterns are becoming almost required.

The groundwork for design patterns is the 23 described in Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the "Gang of Four" GOF). data & object factory provides a convenient, online, C#, reference for these on their website: Steven John Metsker also wrote the book Design Patterns in C#, which covers these standard patterns using C#.

Moving beyond the GOF patterns, Microsoft's Architecture website provides many enterprise patterns for enterprise applications:

The more I use patterns, the more I like them.

Wednesday, January 26, 2005

Advanced Techniques with NUnitAsp

[This was originally posted at]

I just had an article published on 4guysfromrolla, a popular ASP.Net website. It's about using NUnitAsp to test WebForms.

I think this is a pretty good tool, especially because it's open source and has a familiar API.

Friday, January 21, 2005

Good books on Unit Testing

[This was originally posted at]

I've just finished skimming two great books: Pragmatic Unit Testing in C# with NUnit (Andrew Hunt and David Thomas), and Test Driven Development in Microsoft .NET by James W. Newkirk and Alexei.

These are practical guides that show how to use Unit Testing to ensure that the code actually worked in the first place and fortify your code against regression bugs. Both books refer to NUnit (, a Unit Testing tool for .Net based on JUnit. I'll write the next couple blog entries about useful tips I found from these books.


Where to put your Tests: put them in a separate assembly so that they don't ship with production code. Although if you put them in the same assembly, you can test for protected members, there is a work around: make a test class that inherits the production class, make the new class have public accessors. I use to use the #if DEBUG … #endif, but I like this approach a lot more.


Write the tests first: I use to develop first, and then write tests to cover my back. Test Driven Development is about writing the tests first, they fail (the implementing code hasn't been written yet), and then write the code to make the tests pass. This makes you program from a user's perspective (you need to use your own methods to write them in the tests), and gives you a very objective standard to adhere to. You don't burden yourself with everything that might happen down the road – just make the initial tests pass. Because you should have sufficient tests to cover all the functionality of your program, you can confidently refactor and add features later without fear of breaking things.


Useful checklists (from Pragmatic Unit Testing in C#):

What to test, use your Right-BICEP:


  Boundary conditions

  Inverse relationships

  Cross-Check results with other means

  Error Conditions occur

  Performance within bounds

Good Tests are A TRIP:







More later