Completed another Test Driven and Refactoring course for DevJam

This time using C# and the .NET platform. The course went over really well, though we did have some small snafus with the training area in the DevJam office. Nothing that can't be tweaked. I had 15 participants in this class. All participants pair programmed when completing the hand-on exercises and again, I'm totally amazed at how well pair programming goes over when you get people away from their normal work environment. Everyone really grooved on the pair programming thing.

One area that we will need to work on is the mock objects content. We don't have any hands-on exercises for using mock objects and we heard about it in the reviews of the course. I did walk everyone through a demonstration of using mock objects in your unit tests, but I mis-gauged how much interest the participants had in mock objects and the desire to get their feet wet with mock objects. Some of the class participants stay after the course ended and we did another 40 minutes of live coding demos on the use and features of mock objects (using moq for the mocking framework in .NET).

All in all, an awesome two days for me and hopefully for the course participants.

Know your SUT and your mocks

I was working with a colleague of mine tonight and he became confused with his unit test. It was an interesting exchange, so I thought I would write it up. He had a system under test (SUT), a service, that had a number of dependencies. The dependencies were mocked using a mocking framework (mockito in this instance). He was writing a test to get better code coverage in preparation for some refactoring and he started to add an expectation to the SUT. When he ran his test, the test failed, but the error lead you to believe that it was the improper use of matchers within mockito. It took him and I awhile to realize that he was trying to add expectations to a non-mock class. In hindsight, he should have picked up on this right away, as we have a coding convention of naming our mock object instances as mock*. The SUT does not follow this naming convention and hence you should see the problem right away. A little concerned that mockito didn't alert us to the fact that we were trying to add expectations to a non-mock instance. Moral of the story: Make your mock object instances stand out--name them appropriately so everyone knows that it's a mock.

Interesting Microsoft Research paper on the efficiency and effectiveness of TDD

From cLabs Blogki:

http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf

Case studies done on 4 development teams (three at Microsoft, one at IBM) that have adopted TDD. Results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects tha tdid not use the TDD practice. The teams subjectively said that they experienced a 15-35% increase in initial development time after adopting TDD. Very interesting paper.

Powered by Zoundry Raven

.NET Base Class Library types not friendly to mocking with MoQ

I spent some quality time this week driving a design implemented in .NET using unit tests.  It was an enlightening experience and gave me a good glimpse at the quality of the BCL design.  I'm not impressed. We had issues trying to mock System.Net.WebRequest and System.Net.WebResponse and its decendents.  It seems that Microsoft prefers to expose abstract base classes, instead of using interfaces for this.  The aforementioned types are not interface types; they're abstract classes.  We've been using MoQ, a fine mocking framework, at the client I've been working at and I tried to create mock implementations of the System.Net.WebRequest and System.Net.WebResponse types.  No go--these types do not have public constructors.  The non-virtual, non-abstract methods also give MoQ headaches (good write up here about why methods of these abstract class types have to be explicitly decorated with virtual if you want to mock them).  Personally, I'm more fond of exposing interface types, thus alleviating the problem all together.  Very frustrating.  We did continue to unit test and utilized mocks for this, but it forced us to wrap these BCL types with our own types where we could control the virtual decoration.  Yuck!!