Clover.net samples

As I discussed in my last entry, we have now made some sample Clover.net output available. You can now look at a sample coverage report for the NUnit project.

I’m impressed with the level of coverage NUnit’s tests achieve, although it’s a project you’d expect to have good unit tests. So far, however, it seems NUnit is unusual as far as .NET open source projects go. Most I have looked at so far have very little unit testing support evident. I don’t know if this is a cultural difference between Java and .NET open source projects in general or just a function of the Java projects I tend to look at and the .NET projects I’ve managed to find. I’m still looking.

If anyone can recommend some good .NET open source projects with unit tests, please let me know. In the meantime, I’d recommend this article on the new ServerSide for .Net site.

Clover for .NET

Recently at Cortex we have been developing a version of Clover for Microsoft’s .NET platform. This has now reached the alpha stage. We have a tool capable of measuring coverage in C# code and generating HTML reports. This is a native .NET solution and is independent of our current implementation of Clover for Java.

While there is still a lot of work to be done, we would appreciate feedback from people who are prepared to act as alpha testers. If you are able to have a look, please send an email to clover-support@thecortex.net. We can’t guarantee everyone will get a look this time around, as we will focus on a small group but let’s see how we go.

In the next few days I’ll post up some sample reports to show what the coverage reports look like.

Build Tools

A little while ago Stefan was blogging a fair bit about Microsoft’s answer to Ant, MSBuild. I haven’t gone into it in any depth but I think it was an interesting development.

In fact a good friend of mine who is the convenor of a local .Net user group once asked me to do a talk about my experiences with Ant for the .Net folks. It never came off but my tentative title was “F7 is not a build system”. Well I didn’t know what function key you use to do a build in Visual Studio at the time, but you get the idea.

Anyway, I see Stefan has some more blogs on what various people think of build systems.

I came across another, MBuild via Miguel de Icaza’s blog, which has a slightly different take on the idea of build systems.

More C# properties

Somebody was kind enough to add a link in comments to Ted Neward’s response to my earlier blog on C# properties. I appreciate Ted’s insights, although I think he missed my point a little. As I said it is good to have properties as a first-class concept. No question there.

I guess what I really was getting at was that it would be nice to use a simple public field as the implementation of a property, even if that property is declared in an interface implemented by the class. This could be changed to the method style property definition, if required, without changing the type’s interface. Maybe that is a little too much syntactic sugar.

With regard to Ted’s position on components v objects, I don’t take such an extreme position as Ted:

First of all, we need to stop thinking about classes and objects–that’s the 90’s way, and it failed. Simply put, thinking in objects is a terrible idea, and it’s only becoming more and more obvious as time goes on.

I remember Betrand Meyer’s description of component software in his 1999 IEEE Software column:

The phrase “objects are dead, long live components,”although a good attention-getter, does not make much sense technically. All the evidence
suggests that successful component technology must build on object orientation. For one thing, no one knows how to build complex, mission-critical software today without the help of OO techniques. But even more importantly, most of the fundamental ideas that define object technology are just as fundamental to any successful component development

Maybe I’ll have to do a bit more reading …

C# Properties

Since I’m doing some C# programming recently, I thought I’d create a new category (C#) and explore some issues in that area. Many of these issues are probably due to my recent history as a Java programmer coupled with a certain unfamiliarity with C# idioms. I’m not sure how well established C# idioms are at this time, nor do I necessarily like the ones that are.

Let ms start with C# properties. I quite like the idea of properties especially as they group the set and get operations. In other words, the concept of a property is a first class feature rather than something which emerges from the presence of related setter and getter methods.

Now, the question I have is whether you should start with a simple public field and move to a property if more complex behaviour needs to be encapsulated or should you start with a private field and trivial property definitions. The problem is that property access remains distinct from field access at the bytecode level if I understand correctly. That means properties are good for source evolution but not so good for binary evolution. If you do start with a simple field and replace that later with a property, it means recompiling all users of the code. On the other hand, coding trivial property accessors is not terribly exciting either.