Tdd on Dr. Random

More CodeRush Awesomeness

Tue, 15 Dec 2009 15:08:00 +0000

On November 27th, a beta release of the 9.3 version of the Developer Express components, including CodeRush and Refactor Pro! was made available to subscribers. This release is pretty significant to me because it contains a major feature that I have been waiting for for a long time: A Unit Test Runner. There were some teasers released by Mark Miller a while back, which only made me want to get my hands on the tool that much more. My initial impressions are that it is very nice. It is similar to TestDriven.Net in that it provides context menu options to run tests at various levels of granularity (single test, file, project, and solution level) and includes a debug option. At this point it does not contain some of the additional coolness that TestDriven gives you like NCover/Team Coverage and TypeMock integration, but it does have the advantage of being extensible. I know it was extensible because Mr. Miller told me it was extensible (the title “The Extensible Unit Test Runner You’ve Been Waiting For” was a clue). I did not realize how extensible, however, until after I submitted a bug report to DevExpress. The bug I was reporting (the NUnit TestCase attributes were not recognized), it turns out, was already brought to the attention of the DX team by way of a forum post, and they had already planned on correcting it with the next 9.3 release, but I could have saved myself (and Vito on DevExpress team) some time by taking a peek at the source samples bundled with the 9.3 release. Yep, you guessed it, there with a shared source license were all of the test framework implementation projects. So this meant I could whip together my own temporary fix while I was waiting for the next release. It seemed like something that other folks might want to know about, so I thought I would share it here.

More On Testing and "Friend" Assemblies

Mon, 18 Jun 2007 15:33:00 +0000

So if you recall from some of my earlier posts, I’ve talked about the concept of the “Friend” class in C++ and how it could apply to TDD within .Net. Well, today, with the help of Roy Osherove, I just stumbled upon the InternalsVisibleToAttribute within .Net 2.0. This allows you to specify within one assembly, another assembly that should have access to the internal members of your assembly. This is genius, and goes a long way towards allowing you to keep your code encapsulated, while still being testable. If we could just get them to go one step farther, and allow for access to private and protected members as well, life would be good, and there would be no more of this OOD vs TOOD junk.

Struggles with the UpdaterApplicationBlock

Mon, 11 Jun 2007 18:53:07 +0000

The project I’m working on now has a huge need for auto-update. Strangely enough, there aren’t a whole lot of documented solutions for an auto-update application for .Net 1.1. In the 2.0 world you have ClickOnce, which handles those sorts of things for you (and in a way that isn’t terribly difficult to manage as a developer…as long as you pay attention to what your doing), but the only real option you get from MS on this is the AutoUpdater Application Block from the Patterns and Practices guys. I took a look at this when it was in it’s 1.0 version a while back, and really didn’t care for it much. The big reason was that it required you set up an AppStart.exe file, which would take a look at your config file to determine which directory to start the app from. When updates arrived, they were put in new directories based on versions. This seemed like a lot of effort, and a lot of overhead. The good news is that there is now a 2.0 version of the application block, and it looks like it is much more configurable, and has the ability to do inproc updates.

More Thoughts on Language Support of TDD

Mon, 04 Jun 2007 14:21:47 +0000

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.

Using Unit Testing To Document Requirements

Fri, 01 Jun 2007 15:17:02 +0000

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.

I love Mock Objects, but am I a "Mockist"?

Tue, 29 May 2007 15:45:00 +0000

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.

Capturing Programmer Intent

Tue, 02 Jan 2007 16:48:24 +0000

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.