Living .NET... : Review

Being Test-Driven

Manoj G — Sat, 21 May 2005 18:40:00 GMT

NUnit and other popular and freely available unit testing frameworks have been here for enough time for people to absorb unit testing in their .NET development environments. Does just having parallel NUnit test cases for your code suffice to being truly test driven? In the following sections, I have tried to put down what I think about this whole thing.

Putting the very tenets of test driven development at the outset, the answer would be a straight ‘No'. So, what are these tenets? In my opinion, the most important tenets are:

Test-First development
Designing for testability

Test-first development did not make sense to me at first. The very concept of writing unit test cases before writing the application code, appeared to be against the norm. But if you take a hard look at it, you will see a value in writing test cases upfront. You will realize that it is the best scheme in building confidence in the code you are going to construct. Test cases built that way would be the guardian angels of the quality of code you write. In fact, I have started to believe that writing unit tests after you have churned out all the code does not add any value. You would be better off just testing manually - either running through the system's functionality or by just walking through the code. The reason being you, as a developer, would be more biased towards what the code does, rather than what it should actually be doing.

Like test-first development, designing for testability is not something that is typically at our disposition. Well, it is not any new model of design per se; it is just about taking your design and then asking these questions- is this suitable enough for me to write test cases against? Is it possible to create atomic units that can be tested and verified in isolation? This is definitely not as easy, as we typically tight-couple the layers in our application, rendering them difficult to test them as separate units. Design weaves the fabric of the application and hence, this tenet should be treated with a lot of importance. Because, having a design that makes it difficult to test individual units defeats the very purpose of unit testing.

Test-Driven development is a journey that I have embarked upon, and it is not going to be rosy to start with. The slogan - Red=>Green=>Refactor=>Test-Driven is all planted into my workplace, but I know, it would take more than that to imbibe it wholly into my daily work. But, I shall get there eventually.

So, are you ready to be test-driven?

Refactoring and ReSharper

Manoj G — Mon, 11 Apr 2005 06:31:00 GMT

I believe, all the published coding methodologies, practices and guidelines strive to achieve one simple thing: I said it - Simplicity - making things simple, easier to understand, easier to maintain. Refactoring, is one such practice, which we all might have been doing for ages, perhaps without knowing that the practice is labeled 'Refactoring'. By definition, Refactoring is all about changing the structure of code without changing its expected behavior. Why do it - to simplify, simply put.

There are many refactoring techniques one might want to use with respect to object oriented programming. I wouldn't enunciate all of them here; I would recommend Martin Fowler's most excellent book for the same. Consider one such common technique - Rename. As benign as this might appear, Renaming is one of the most powerful steps towards simplicity. Be it a member variable, a formal parameter, a method name or the class name, proper (re)naming should portray the true intent and eliminate the need for comments. Another common technique is Extract Method. More often than not, a method gets bulky and its real intent starts becoming hazy. At such times, you may want to break it up into smaller methods so that the code becomes more 'readable' and hence maintainable.

Now, the techniques that I have just mentioned require some amount of manual effort in the code editor (IDE). For instance, changing the name of a member variable would mean changing them in all class methods where it is used. These changes could be drastic, if the members/methods are public. Manual effort is but, error prone and typically, refactoring entails unit tests to certify that expected behavior is not violated. To that end, wouldn't it be great to have a tool of sorts which automates most of such common refactoring techniques? VS.NET is a far cry in this respect; so, ReSharper comes to the rescue!

Well actually, the very purpose of this blog post was to share with you, my experiences of working with this fabulous tool. ReSharper is essentially, a refactoring tool that comes as an add-on to the VC# IDE provided by VS.NET 2003. In addition to facilitating some refactoring techniques, ReSharper provides enhanced navigation, formatting and intellisense enhancements over and above what VS.NET provides, which make C# development even more pleasurable. There is good reason to see why VS 2005 provides most, if not all of what ReSharper provides already.

Well yes, as the name would suggest, ReSharper is a tool that works only with C#. I don’t want to get too philosophical here, but it seems as if VB.NET was perhaps, alienated from ReSharper for the same reason why Refactoring (or most of it) was opted out of VB 2005. (Ofcourse, time and scope, among many other things could have been a reason). In my opinion, refactoring is a technique that cuts across all languages and has to be adopted (I must say religiously) by all programmers, whatever be their language of choice for development. I am also of the opinion that IDEs have to provide refactoring support in some form or the other.

Nonetheless, ReSharper has been one of the best developer tools I have ever worked with. It is truly a developer productivity enhancer and I personally would recommend ReSharper for every C# developer working on VS.NET 2003. Its more than worth 149$; go get your copy today. With ReSharper, refactoring is fun too !

COmega

Manoj G — Thu, 29 Jul 2004 17:27:00 GMT

COmega is a research language (from MSR, where else) which gives really powerful extensions to C#.

To summarize, there are two extensions : X# (Xen) and Polyphonic C#. Check out COmega Home for more on what these really are.

You can download the COmega compiler preview from the MSR downloads page. This includes VS.NET templates, command line tools, documentation and lots of samples.

I was blown away by the raw power Comega provides as a programming language. So much so, that I am really interested in joining a COmega SIG, if there is one, or probably start one, perhaps !!!

I have not yet really delved into all aspects of the language (especially Polyphonic C#), but will do it and will definitely come back with more posts on the same.