Thinking about my earlier post discussing the OOP vs TOOP problem, I mentioned at the end that the best solution to this problem in my mind would be integrated language support for test classes. Specifically, a way to let the Compiler/Runtime know that a specific class is a test class, and should therefore be able to access any and every property of a class. It occurred to me that such blatant intrusion into the privacy of a class is not unknown in the programming world. C++ has the notion of a “Friend” class. This is a class that can access all members of another class regardless of their protection level. To keep things civil, so that just any class can’t declare itself to be a Friend of any class it wants, the class that the Friend class would be accessing would declare specifically that classes X, Y and Z are fiends, and so can have free reign. Granted this is considered to be rather scary, and one of those features that makes C++ an ideal tool for shooting ones own foot off. ...

Here is something I’ve been kicking around in my head for a while, and thought I would put it down in more or less a “permanent” format so maybe I’ll do something about it sometime… Back when I was first trying to get my head around TDD, one of the things that I found most clarifying was an idea I first saw in Test Driven Development in Microsoft .Net (Microsoft Press). The idea is that you write tests based on your requirements. So as a developer, you should have hopefully been given a list of requirements by someone for the project you are working on. When you go to build the software you start looking at the requirements list, and the pick on (usually a simple one) to start implementing. Once you have your requirement you start brainstorming tests that can be implemented to fulfill that requirement. Once you can no longer think of tests for a requirement, you move on to the next one. After that once you have run out of requirements, then your done writing the software. ...

Its been a while now, but Roy Osherove posted some articles about Testable Object-Oriented Programming. That is, designing your code to be testable by default. The part of this that is most interesting is that he suggests that sometimes you need to sacrifice encapsulation in favor of being able to test your code. This is where one of the biggest flaws with TDD (at least in my opinion) begins to show. I think the idea of making code testable breaking encapsulation is one of the only arguments against TDD that I have heard that I can’t give a good defense for, and it makes me crazy. ...

I have officially crossed over….I am now using Mock Objects in my tests and loving it. After much humming and hawing, and trying to figure out how to write truly effective tests, I decided to give it a go, and so grabbed a copy of Rhino Mocks and started the grueling task of converting some data access code so that I no longer needed a database to run the tests. It took a little bit to get my mind around the new way of thinking, but I have to say it worked great. I’m now able to test my data access routines with complete success, and about a 95% code coverage rate. This is all on top of the fact that I’m using Enterprise Library (for 1.1) for data access and exception handling. ...

I’ve been reading the “Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries” book recently, and I came across a section discussing interface design, which had direct bearing on one of my earlier posts regarding programmer intent. They basically state flat out that you should never use marker interfaces in .Net. Instead, you should favor custom attributes, and then test the type for that attribute. This was interesting to me, since I have been trying to determine what, if any, value marker interfaces would have in .Net. In the Java example I cited, one of the benefits was that the JavaDoc information associated with the interface would then be attached to the class, so you would have clear intent from the developer when the interfaces were used. .Net documentation comments don’t carry that same direct association…granted, when the documentation is generated, most of the time there will be a link to the interface definition..but it’s not quite the same. On the other hand, generally a custom attribute will not even provide that link, so from a doc standpoint there is less information available. ...

I was listening to the ArCast recorded with Scott Hanselman earlier today, and he was talking about the idea that Non-Software artifacts should approach zero. If you’ve seen some of his posts, or listened to some Hanselminutes podcasts, you have no doubt come across this idea before. I like this particular phrasing mostly because it gets to the heart of what I think one of the most often overlooked aspect of the programming process is; Namely, the intent of the programmer. ...

I just learned that Microsoft changed the way unhandled exceptions in Threads are propogated in .Net 2.0 vs the way they worked in 1.1. With 2.0 any unhandled exceptions in a thread will not only cause that thread to exit, but will also be bubbled up to the thread that started the offending thread. Overall, I think this is a good thing, since not only will it force people to handle exceptions within their thread code, but it will also eliminate the problem of processes mysteriously stopping if there is an unhandled exception on a thread. It will, however, cause some serious grief for any developers not expecting that sort of behavior. I’m sure I’m not the only one who has seen less than steller multi-threaded programming tactics in applications which should be better behaived (heck, I’ve done my share of shoddy thread handling in the past). ...

It just goes to show that there are always little surprises waiting around the corner. I’ve been looking at least casually at .Net 2.0 since Beta 2, and I even read through the “What’s New” for C# 2.0 to see if I missed anything. Somehow I managed not to notice Implicit Delegate Assignment (or at least that’s what I’m calling it). It is now possible to assign a delegate using just the Class and Method name…you no longer have to create a new instance of the delegate type. Not a huge thing, I know, but for those of us who are easily impressed it’s, well, impressive. ...