Someone once said something like: “Code is written once and read many times”. That is why I propose not to use RhinoMocks’ AssertWasCalled method for methods that accept parameters. Sure, it’s written faster than using GetArgumentsForCallsMadeOn, but check out the error message you get for this: var expectedMessage = “RhinoMocks baby!”; var actualMessage = “RhinoMocks dude!”; var fooMock = MockRepository.GenerateMock(); fooMock.Bar(actualMessage); fooMock.AssertWasCalled(x => x.Bar(expectedMessage)); Your test will fail with the following message: IFoo.Bar(“RhinoMocks baby!”); Expected #1, Actual #0. To fix

After having applied TDD for several years now, and after having assumed my colleagues do the same, I have been surprised lately to hear how many developers write their tests after their code. Test-driven development is meant to be: Write a test See that it fails (and fails correctly) Write your code See that your test passes Refactor (and see that your test and all others still pass) This has led to the well-known (for some) red-green-refactor adage. If you

When asserting the content of collections, lists, dictionaries,… in unit tests, don’t do this: Assert.That(this.result.Contains(this.expectedResult1)); Assert.That(this.result.Contains(this.expectedResult2));   Or this: Assert.AreEqual(this.expectedResult1, this.result[0]); Assert.AreEqual(this.expectedResult2, this.result[1]); What if you implemented your method wrong, and the result contains more than two elements? Unless you’re totally not interested in the size of the result, always check if the collection is as big as you expect it to be: Assert.AreEqual(2, this.expectedResult.Count); Assert.AreEqual(this.expectedResult1, this.result[0]); Assert.AreEqual(this.expectedResult2, this.result[1]);

Thinking about it, the team I work in has quite a lot of ‘security checkpoints’ for our code. We try to put as many pieces of code under unit test. However, we are often hindered by an old framework that can be described as a sort of ‘CSLA meets Active Record’. If unittests are impossible, we will make fit-tests (using FitSharp). We develop using the Scrum methodology, and, after you finished your task, you can stick the post-it in the