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.
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 email@example.com. 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.
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 …
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.