One of the common scenarios I find myself in is needing to be be able to mock an object instantiated during the lifecycle of another object. For example, a service object might need to, on receiving one message, create an entity, and on receiving another message, call some method on that entity. The easy way to do this is to make a builder as a service for the object needing construction, and mock out the builder object to return a mock. So, for that service-layer code I'm trying to test... 1: public...

I often have found that working with small, immutable objects can be very helpful. First off, they are extremely easy to test, typically not needing any sort of mocking involved. Second, due to their immutable state, you can easily override Equals to use to your advantage. The advantage I'll talk about today is the ability to introduce a new test seam that doesn't depend upon inversion of control to be able to test an object. Suppose I'm writing an object that will represent a query. The query should...

Note: For users of NUnit, version 2.5 will have an Assert.Throws method. This version is currently available in alpha status. On the ALT.NET mailing list, there was a discussion about using the [ExpectedException] attribute in NUnit. Most people have come to figure out that using the ExpectedException attribute on your tests has disadvantages. First, your test will not be able to pinpoint exactly where the exception is supposed to occur. You could get false negatives for having the exception thrown...