Using attributes like [ExpectedException] can obscure intent because they apply to the whole method instead of a specific call you're checking. To make intent totally clear and prevent unexpected bugs, you should wrap just the statement you're expecting an exception from in a try/catch:

int y = 0;

try
{
    int x = 1 / y;
    Assert.Fail("Exception not thrown DivideByZeroException");
}
catch (DivideByZeroException)
{
}

In addition, at times the same exception is thrown, but with different descriptive messages and in the interest of checking correctness we need to check the message as well.  To help achieve DRY, clarity, and expressiveness, I've created some helper methods for my unit tests to deal with testing proper exception throwing.  Note that to be totally by the book, you likely should be creating special custom exceptions for each type rather than checking the message strings, but this can be superfluous at times so the option is here.

public class SpecHelpers
{
    public static void ExpectException<T>(Action methodCall) where T : Exception
    {
        bool caught = false;

        try
        {
            methodCall();
        }
        catch (T)
        {
            caught = true;
        }

        if (!caught)
            Assert.Fail(String.Format("Expected exception {0} not thrown"));
    }

    public static void ExpectExceptionMessageStartsWith<T>(Action methodCall, string startsWith) where T : Exception
    {
        bool caught = false;

        try
        {
            methodCall();
        }
        catch (T ex)
        {
            if (!ex.Message.StartsWith(startsWith, true, null))
                Assert.Fail(String.Format("Expected exception {0} thrown, but message didn't start with \"{1}\".  Message: \"{2}\"", 
                            ex.GetType().FullName, startsWith, ex.Message));

            caught = true;
        }

        if (!caught)
            Assert.Fail(String.Format("Expected exception {0} not thrown"), typeof(T).FullName);
    }

    public static void ExpectExceptionMessageContains<T>(Action methodCall, string contains) where T : Exception
    {
        bool caught = false;

        try
        {
            methodCall();
        }
        catch (T ex)
        {
            if (ex.Message.IndexOf(contains, StringComparison.InvariantCultureIgnoreCase) < 0)
                Assert.Fail(String.Format("Expected exception {0} thrown, but message didn't contain \"{1}\".  Message: \"{2}\"", 
                            ex.GetType().FullName, contains, ex.Message));

            caught = true;
        }

        if (!caught)
            Assert.Fail(String.Format("Expected exception {0} not thrown"), typeof(T).FullName);
    }
}

 

 some example calls:

private bool ThrowEx()
{
    throw new Exception();
}

private bool ThrowExContains()
{
    throw new NullReferenceException("a special message");
}

[Test]
public void TestExceptionWrapper()
{
    // .NET 3.5 style with lamba notation
    SpecHelpers.ExpectException<Exception>(() => ThrowEx());
    SpecHelpers.ExpectExceptionMessageContains<NullReferenceException>(() => ThrowExContains(), "special");

    // .NET 2.0 style with anonymous delegate
    SpecHelpers.ExpectExceptionMessageContains<NullReferenceException>(delegate() { ThrowExContains(); }, "special");
}

These code samples are from:

http://www.ayende.com/Blog/archive/2008/06/06/Scratching-an-itch-NMemcached.aspx

    public class SystemTime
    {
        public static Func<DateTime> Now = () => DateTime.Now;
    }

At first I was wondering what the point of that was.  Does he really hate the name DateTime?  Was he planning on changing the class one day to not use DateTime.Now and wanted a layer of indirection?  Turns out that was on the right track, but not exactly it.

https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/experiments/NMemcached/NMemcached.Tests/Memcache_FlushAll_Tests.cs

After seeing his unit tests I figured it out.  He changes the value of the static function SystemTime.Now from being a function call that is evaluated each time to returning a burned in value of January 1, 2000.  Now his code that checks for the current time to see if something is expired will see that date.  He tests this in "When_getting_item_that_has_been_expired_will_return_empty_result()".  You could do something messier like adding a cache item that is set to expire in 2 seconds, sleeping 2 seconds, and then checking that it's gone, modifying your classes to allow passing in a DateTime or setting it via reflection, but this is so much neater and doesn't introduce delays into your unit tests which should run as fast as possible.

If you're like me and always change the default install directories, you've probably run into this.  A workaround is here.

Test-driven development, Unit Test, VSTS, NUnit, TestDriven.NET, whats all this?

Good Overview of Types of Testing and TDD 

Testing Theories Part 1 - Classical vs Mock Testing
Testing Theories Part 2 - Unit Testing with Inversion of Control Pro's/Con's
Testing Theories Part 3 - IoC Containers (Castle Windsor, Spring.NET), AutoMocking Containers
Testing Theories Part 4 - TypeMock Isolator - The Dark Horse of Unit Testing?

A lot has been discussed on the pro's/con's of IoC for the purposes of unit testing and in general it has been framed as for or against TDD.  This is actually not entirely correct.  TypeMock Isolator has the notion of Reflective Mocks that allow setting up expectations on actual classes and not just interfaces.  I've been fascinated with the idea of TypeMock and it introduces the concept that you don't HAVE to modify your design for testability using IoC, interfaces, and factories strictly for testing purposes.  At the Philly .NET Code Camp in January the ALT.NET track was very heavily into testability via IoC.  Also as part of that track, I attended Don's presentation on design patterns and I had asked him afterwards how he achieved testability in his sample code when he did not implement IoC and the design pattern implementation would have made it difficult to do so.  He mentioned using TypeMock, a product I had been reading a lot about, and it definitely made me think of this product more seriously.

This article, Stop Designing for Testability by TypeMock Isolator evangelist Eli Lopian also promotes the bold assertion that IoC is not the only path to testability.  The article itself is very thought provoking as well as the discussion in the comments.  One particular comment by narsyseth (sadavoya) draws a great a parallel to white box and black box testing.

"Hi Guys,
This has been an interesting thread to watch. I see this moving toward a general discussion on how to test. It seems to me that there are two types of unit testing, white box and black box. Both are equally useful at different times. Black box unit tests would test an object using it's interface. The onus is on the production code to provide the flexibility to inject mocks, but those mocks require limited knowledge of what they are "mocking". White box tests would involve mocks that have more intimate knowledge of exactly how the unit they are "mocking" works. It seems to me that Typemock leans toward the white box approach, while the use of factories is more black box. I realize it's not so clear cut, but that's a pattern I'm seeing here.  Regardless of whether or not that's true, where I see something like Typemock really shining is when writing tests for legacy code, when you have no tests to begin with. Assuming the legacy code is not written in a test-friendly way, using the black box approach is extremely difficult: you can't refactor the legacy code to support mock injection because without tests you can't be sure you won't break it. On the other hand you can't inject mocks because the legacy code doesn't support it. Typemock breaks this vicious circle, it seems, by allowing the injection of mocks without touching the production code. This way you can write tests, then safely refactor the production code. Voila, the legacy code can now be brought into a testing cycle and the 21st century. For me, this is the most exciting aspect of Typemock."

Some detractors mention that since TypeMock will let you test nearly anything, you'll have no incentive to adhere to any of the solid principles that come along with testability via IoC such as designing to interfaces, isolation, lower coupling, and single responsibility.  That simply doesn't seem to be a clear argument.  Having a more flexible tool doesn't automatically make you a sloppier programmer.  Ideally your own discipline should motivate you, not the limitations of a tool.

Testing Theories Part 1 - Classical vs Mock Testing
Testing Theories Part 2 - Unit Testing with Inversion of Control Pro's/Con's
Testing Theories Part 3 - IoC Containers (Castle Windsor, Spring.NET), AutoMocking Containers
Testing Theories Part 4 - TypeMock Isolator - The Dark Horse of Unit Testing?

IoC can certainly be done manually without the help of a container, but there are advantages to using one.

1. Can configure external dependencies in config for class so each time it's used the dependencies are automatically wired up.  No setting properties or passing lots of interface reference parameters each time.
2. Can you separate config for unit test, pre-production environment staging, and production so no code changes for where your dependencies/resources come from.  Integration tests on a test environment can use a local copy of the DB or completely mock the data layer altogether.  Code based config right in the unit tests is also a possibility.
3. The container saves you the trouble of writing specialized factory classes to configure your objects for various roles.
   
4. Dependency lists serve as a form of implicit documentation for your classes and how they are connected. 

AutoMockingContainers automatically create dynamic mocks for all dependency references needed for the class in test and the specific portion of functionality being tested can then be setup with expectations.  It cleans out the setup part of your tests a bit and cuts down on repetition.

JP Boodhoo and David provide similar BDD base class implementations using Windsor AutoMocking container to further clean up redundant test code.

---

Resources

Castle Windsor

http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart1.aspx
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart2.aspx
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart3.aspx
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart4.aspx
http://msdn2.microsoft.com/en-us/library/aa973811.aspx

Windsor AutoMockingContainer

http://blog.eleutian.com/2007/02/23/TestsAutoMockingIoCContainer.aspx
http://blog.eleutian.com/2007/08/05/UsingTheAutoMockingContainer.aspx
http://www.ayende.com/Blog/archive/2007/06/08/The-Auto-Mocking-Container.aspx

Spring.NET

http://www.developer.com/net/csharp/article.php/10918_3722931_1
http://forum.springframework.net/showthread.php?t=4201 - AutoMock Spring
http://www.ibm.com/developerworks/library/j-mocktest.html - Java example but still useful for reference

Helper Base Classes for TDD/BDD
http://codebetter.com/blogs/david_laribee/archive/2007/12/17/approaching-bdd.aspx
http://codebetter.com/blogs/jean-paul_boodhoo/archive/2007/12/19/bdd-specification-base-class.aspx

 

Pro

What do software engineer's do?

A well written description notably devoid of terms like "code monkey".

It’s All about Assigning Responsibilities

This example really hit home for me.  I am faced with a very similar legacy code design where some processing takes place and an e-mail is sent out.  My current tests consist of integration tests that outright send me an e-mail that I have to confirm manually.  Having these tests was far better than nothing at all, but their design never sat well with me.  They were from an earlier attempt at writing tests before I truly understood or had time to delve into IoC, mocks or refactoring for testability.

Now half a year after having written the tests, I understood that I could use a mock to determine if an e-mail was sent without sending an actual e-mail.  But how would that help me determine if the contents of the e-mail were correct.  After reading Jeremy's article it became clear that my code design itself was flawed and I need to simply separate the generation of the e-mail text from sending the e-mail.  It's such a simple idea and makes so much sense.

http://www.phillydotnet.org/

This Saturday I attended the Philly Dot Net Code Camp.  It was very well organized, especially considering it was a free, volunteer run conference.  I spent most of my time in the ALT.NET track and really found some excellent information and presentations.  I talked with a few of the guys and had a few of my misunderstandings about TDD and IoC containers cleared up.  I have a lot to still digest and a few things to still try and probably more questions to come.

I'm currently wrestling with the idea of using TypeMock, Rhino Mocks, or both and I see a lot of heated discussion about the merits of both.

It has been recommended for SQL 2000 and 2005 to enable trace flag 1118 to disable mixed extent allocation.

Recently a hotfix came out for SQL Server 2005 SP2 that resolved a potential contention issue with the flag itself: http://support.microsoft.com/kb/936185

Linchi has not been able to duplicate the issue, but the hotfix is there if needed now.  Hopefully the hotfix will make it into an SP3 sometime so setting this flag can be done with more confidence that it's not going to make contention worse.

Two interesting techniques I came upon:

http://www.sqlteam.com/article/sql-sever-2005-using-over-with-aggregate-functions

Retrieve aggregate data using OVER(Partition by ...) rather than doing another join

http://weblogs.sqlteam.com/jeffs/archive/2007/06/12/60230.aspx

Using GROUP BY in some cases to avoid a self-join

I've always tried to make it a point to read a lot about the industry and constantly shifting and improving methods and best practices.  Sometimes the buzz dies down after a bit -- I was particularly amused to find people tired of the lofty promises of EJB and going back to basics with POJO.  Other times it grows to a roar.

The promises of unit testing and refactoring were being extolled for a while, but I must admit it took some time and much reading for it to sink in.  If you're smart enough to make tests to exercise your code cases properly and didn't miss anything, you probably would have handled all those cases properly when you were coding anyway, right?  Perhaps, but what about changing that code 6 months from now?  What about someone else changing that code?  I must admit I find a certain comfortable simplicity in writing unit tests to exercise the boundaries and coverage of a piece of code.  After doing a few, it starts to become automatic and not take as much time as you would think.  It keeps you honest.  Even the best programmers can be burned when making just a quick last minute change that wasn't expected to change another area of code, but invariably does and most people are terrible at methodically manually testing their code countless times.  Too many habits of doing things the same way every time leads very often to surprised cries of "But it worked for me.".  Unit tests also add a margin of comfort to refactoring.  Too often we let bad code persist and create maintenance headaches for years because it's not well suited for automatic or manual testing.

So I'm starting to believe now and writing my unit tests where I can going forward with new code and adding them to existing code when making changes.  As time goes on, existing code will be retrofitted for testing and testing code coverage will increase.  I'm definitely still learning and experimenting on testing methods and will occasionally post snippets or ideas I'm working on.

Ever since I started x86 programming, I've always found communities of individuals sharing knowledge and collaborating from the early days on local BBS's and FidoNet to forums and blogs today.  It's quite ironic considering all the jokes about anti-social programmers that the field has had such a long history of mostly volunteer support communities.  I cannot imagine being nearly as productive today if I had to work without Internet access.  The industry moves so fast nowadays that paper documentation is outdated before it's published and much development is based on components on top of frameworks taking advantage of (hopefully) well thought out and tested code as a base.  I've learned so much reading from others often tackling the same types of problems I am.  I've often meant to share some of my own experiments and ideas in return, but never made the time or had the place for it.  I hope to make this blog the place for it.

As of last year, I've also been participating in in-person communities and events like NJSQL, Sql Pass, and soon my first CodeCamp.  It's been fantastic meeting community leaders, MVP's, and Microsoft developers and gaining their firsthand insight.  I hope to one day present some of my own topics and experiments at some of these venues.